dev@grizzly.java.net

Re: Is class of attribute employed as a state holder of GIOP server which maintains session state per connection ?

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Tue, 09 Mar 2010 18:06:41 +0100

Hi Ming Qin,

the GIOP parser in 2.0 samples - is really simple GIOP header parser,
which doesn't try to implement real GIOP protocol complexity.
So your concerns are correct, but we didn't try to implement real GIOP
protocol.

WBR,
Alexey.

On Mar 9, 2010, at 3:12 , ming qin wrote:

> Like to be more specific on Grizzly 2 version for
> classGIOPParserFilter : Grizzly version is Grizzly 2.0.0-M3
>
>
> Ming Qin
> Cell Phone 858-353-2839
>
> --- On Mon, 3/8/10, ming qin <mingqin1_at_yahoo.com> wrote:
>
> From: ming qin <mingqin1_at_yahoo.com>
> Subject: Is class of attribute employed as a state holder of GIOP
> server which maintains session state per connection ?
> To: dev_at_grizzly.dev.java.net
> Date: Monday, March 8, 2010, 6:02 PM
>
>
> In Grizzly 2Dot0, instances of
> com.sun.grizzly.attributes.Attribute are functioned by
> GIOPParserFilter to maintain GIOPParseState and
> PreparesedGIOPMessage for GIOP server.
>
>
>
> Is this approach of employing attributes being related to
> com.sun.grizzly.Connection after channel is established as the
> solution of session state oriented protocol for maintaining session
> state per connection?
>
>
>
>
> Below is Ken Cavanaugh’s description on post about GIOP's
> session state per connection.
>
> https://grizzly.dev.java.net/servlets/ReadMsg?list=dev&msgNo=910
>
>
> “the GIOP specification requires that a response to a request
> be sent on the same connection as the one on which the request
> was received. In many ways,
> this is a defect in the protocol, since a big reason for the
> requirement
> is the fact that GIOP maintains session state per connection
> (one session only per connection). But the way GIOP is defined,
> a connection with pending responses must be kept open, or
> the request will terminate with an error. This also means that we
> have non-trivial state per connection to keep track of
> suspended
> client threads waiting for responses on the client
> side. The server
> side is smaller, but we still need information about pending responses
> and fragmented messages not yet completely received.
> “
>
>
> Ming Qin
> Cell Phone 858-353-2839