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.
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?
Thanks,
Ken.