Salut,
Ken Cavanaugh wrote:
> 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?
>>
> I just want some place to put per-connection state. I don't want to see
> a ThreadAttachment exposed to the Grizzly API, but I don't care if it is
> used
> internally or not.
Can you explain why you don't want to see it? Right now it is exposed
and allow you to "attach/evil" your state to the SelectionKey :-)
>
> From my point of view, the main problem here is getting things like
> attachment -> connection wrapper -> stream -> buffer -> slab (indirectly)
> and prevents proper resource reclamation when connections are closed for
> any reason. Perhaps per connection state should implement the Closeable
> interface, so that Grizzly can close such state if Grizzly chooses to
> close a
> connection?
That makes senses, but just to make sure I get it properly, it also
means that if a Connection/Closeable object gets closed, the associated
SelectionKey must be canceled **AND** its attachment removed. That the
biggest issue I've with attachment. If you forgot to clear them, then
welcome the evil SelectionKey.attachment :-)
A+
-- Jeanfrancois
>
> Thanks,
>
> Ken.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>