>
Hi,
> .
>> I think the best Grizzly can do is maybe like has been suggested to
>> have a nice closeable method. (and maybe in debug modus attach an
>> last ready timestamp to Connection)
>>
> I agree, and I think we briefly mentioned this in the last Grizzly
> meeting.
> Grizzly should be able to close resources associated with a
> connection,
> and the best way to do that is to have such resources implement
> Closeable.
> For example, the Grizzly connection cache will close idle
> connections, and
> so it must be able to guarantee that resources associated with an
> idle connection
> are reclaimed.
>
> Similarly, if the protocol decides to close a Grizzly connection,
> all Closeable
> resources associated with that connection should be closed.
>
> One of the ideas we are playing with is basically to use a
> generically-typed
> attribute class to associate state with a Connection (this was
> discussed on
> the Grizzly alias on 2/15/08-2/19/08). This would work something like:
>
> static final Attribute<Foo> foo = new Attribute<Foo>( Foo.class,
> "FooAttribute" )
>
> Then we can access the attribute as:
>
> foo.get( connection )
>
> and set it as
>
> foo.set( connection, fooValue )
>
> If Foo implements Closeable, it would be easy for the Connection close
> code to iterate over all attributes, closing those non-null
> attribute values
> that implement Closeable.
>
> Also note that the implementation amounts to an ArrayList associated
> (perhaps)
> with the SelectionKey attachment. It would be easy to ONLY associate
> the
> ArrayList in those cases where an Attribute is actually set, so if
> the mechanism
> is not used, there is no Attachment overhead.
>
Absolutely agree Ken.
Typed Attribute mechanism, which you proposed, is already in Grizzly
2.0 :)
Thanks.
WBR,
Alexey.
> 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
>