>> This is my favorite :))
>
> Me too, but with a different taste :-) :-)
hehe :))
>> 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.
Right, by default Connection will have nothing associated - so it will
be easy gc'ed by JVM, absolutely the same way as Long.
>> 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
By default Connection MUST NOT contain any associated resource. And we
need to keep this object as small as possible.
Thank you!
WBR,
Alexey.
>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>