Salut,
Ken Cavanaugh wrote:
> ash2k! wrote:
>> Hi!
>>
>> Jeanfrancois Arcand-2 wrote:
>>
>>> What peoples thinks?
>>>
>>>
>> I asked some time ago about this thing
>> http://www.nabble.com/Question-about-http-on-grizzly-tt16846432.html - i
>> implemented this server (without grizzly, just plain NIO) and i use a simple
>> hashtable for storing connection related info in it. selectionkey is used as
>> a key and special class with connection info as a value in hashtable. why
>> not to implement it like this? i do not use selectionkey attachment bacause
>> of your blog :) - i agree that there are those disadvantages that you
>> pointed out. unneded entries from hashtable are removed whenever i close a
>> channel. also it is rather convenient to iterate throught connections.
>>
> My concern with using a Hashtable is that it forces a
> Hashtable lookup on every read event. An attachment effectively
> just puts the data in a place known the NIO so that it can be
> returned directly, avoiding the lookup overhead.
I agree...but I still think that a good framework (like Grizzly :-))
should not be build with the assumption that some framework state be
attached. It is a waste of memory IMO. Of course there are situation
where you need to attach, and that case is handled right now by the
ThreadAttachment API. But only when it is required. By default, we just
attach a long for the keep-alive mechanism.
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