Salut,
Oleksiy Stashok wrote:
> This is my favorite :))
Me too, but with a different taste :-) :-)
>
> 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.
Agree. But the Long cannot carried application data, which I consider
safe (and a SelectionKey + Long will eventually get gc()). As for
CallbackHandler, SSL and ProtocolParser, I agree we attach, but again no
user data unless ThreadAttachement is *explicitly* requested.
>
> 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.
+1
>
> 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.
+1
>
> 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.
Agree, except with your proposal, we will attach a Connection object
*all* the time, where ThreadAttachment are always attached on request.
That's my only issue, but since we are planning to keep it small (at the
minumum a place holder for the long), then +1
>
> One thing we need to make sure is that Connection, by default, will be
> really light object without any important resource associated.
+1
Thanks!
-- Jeanfrancois
>
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>