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 too don't like Hashtable approach here. Alexey's proposal seems like
a good one to me. +1. ( I know, Jeanfracois says selection key
attachments are evil...!!?)
Jeanfranscois was mentioning that, we can re-construct the
ConnectionObject from the selectionKey's channel. Thought that would
help gain access to the connectionObject
but, we would have problems in obtaining lock() on the connection while
doing mutltiple writes from various threads. Instead of reconstruction,
if we could get the same connectionObject using say an api like
context.getConnection().. that would suffice too.
Many thanks to Alexey for considering most of the users' input in coming
up with a good proposal of Grizzly 2.0
-hg