users@grizzly.java.net

Re: incoming packets processing order

From: Amy Kang <Amy.Kang_at_Sun.COM>
Date: Wed, 18 Mar 2009 09:05:08 -0700

Hi Alexey, thanks for the reply.

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 ?
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
> >
>