Hi Amy,
>
> By 'packets' I mean either TCP packets or application messages,
> its the processing order that matters to me. When the client sends
> a sequence of messages on the same connection, I need the server
> to process these messages on that connection in the same sequence
> order.
>
> on the server side,
> grizzly thread-1: call protocol parser filter
> call protocol filter
> --->my server-handler processing message#1
>
> while I'm using grizzly thread-1 processing message#1, is it
> possible the next message - message#2 will be picked up by
> grizzly thread-2 and start next protocol chain processing ?
No, Grizzly processes incoming requests sequentially.
WBR,
Alexey.
>
> If yes,
>
>
> 1. The server can potentially process client messages on
> the same connection in a different order from how these
> messages were sent by client, e.g. process message#N
> before message#N-1;
>
> 2. Multiple grizzly threads can potentially access the same
> server-handler that is stored in grizzly context with
> CONNECTION scope attribute holder while processing
> incoming data for the same client connection.
>
> Can #1 and #2 happen ?, if yes, is there a way to prevent it
> - that is - enforce serial processing on 1 connection when
> using grizzly ?
>
> Thanks,
> amy
>
>
> ----- Original Message -----
> From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
> Date: Wednesday, March 18, 2009 2:58 am
> Subject: Re: incoming packets processing order
> To: users_at_grizzly.dev.java.net
>
>
>> Hi Amy,
>>
>>>
>>> On 1 socket connection, if client sends packet1, packet2,
>>> packet3, ...
>>> on the server side, does Grizzly ensure the packets (or the
>>> bytes) are
>>> proccessed (pass to the protocol chain) in the order they arrives ?
>> If we talk about TCP sockets - then yes, packets will come in the
>> same
>> order.
>>
>>> That
>>> is, if I associate a handler object to a CONNECTION scope attribute
>> to
>>> the context, I should see a serialized access to the handler
>>> (except
>> on
>>> connection close events) ?
>> Hmm, can you pls. provide more details here?
>>
>> WBR,
>> Alexey.
>>
>>>
>>>
>>> Thanks,
>>> amy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>