dev@grizzly.java.net

Re: [Grizzly2.0 - Issue 3] Attaching a Connection object to the SelectionKey

From: Oleksiy Stashok <Oleksiy.Stashok_at_Sun.COM>
Date: Thu, 19 Jun 2008 13:38:52 +0200

This is my favorite :))

Talking about attachments, currently in Grizzly 1.x we use following
attachment types:
Long: is used *all the time* for *all* server side connections
ThreadAttachment: is used for SSL, ProtocolParser
CallbackHandler: for *all* client side connections

as we see even if we don't like attachments, we use them quite widely
even in current Grizzly code, especially Long and CallbackHandler.

So, what I propose is to generalize attachments, so it will be always
one type of attachment: Connection, where it will be possible to save
some connection related state.
Connection will be some small object, which, by default, will not have
any ByteBuffers or sockets or whatever associated with it. So for me
having Connection as attachment will be almost equal to having Long
attachment.

But what Connection will propose us - is general way of accessing
connection state attributes and common IO operations implementation.

So at one side Connection, by default, would be almost as light as
Long, or, if developer will decide to store the connection state - as
functional as ThreadAttachment.

Talking about possible nightmare - I think possibility of having
resource leaks with Connection is absolutely the same if compare with
ThreadAttachment. Because it's possible to save ByteBuffer to
ThreadAttachment and forget to release it - so, I don't see any
additional danger Connection will bring.

One thing we need to make sure is that Connection, by default, will be
really light object without any important resource associated.

Thanks.

WBR,
Alexey.

On Jun 18, 2008, at 21:04 , Jeanfrancois Arcand wrote:

> Salut,
>
> my nightmare is back[1] :-) Alexey is proposing to attach a very
> simple object called Connection to the SelectionKey. This Connection
> object object would persist some connection information when the key
> is registered back to the Selector. I've never been a fan of
> attaching object to the SelectionKey, and I do think we can
> reconstruct those objects between transaction instead of attaching
> them.
>
> Alexey's proposal is also to get rid of ThreadAttachment (hide the
> concept to the users). I was under the impression it was a good
> idea, now I'm no longer sure :-)
>
> What peoples thinks?
>
> A+
>
> -- Jeanfrancois
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>