Harsha Godugu wrote:
> 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...!!?)
LOL :-)
>
> 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.
Hum..can you elaborate :-) You will re-construct the object from either
a pool of instance or by doing a allocating a new one every there there
is an OP_xxxx ready.
Instead of reconstruction,
> if we could get the same connectionObject using say an api like
> context.getConnection().. that would suffice too.
Playing the devil advocate here I would say you can still offer the same
API by reconstructing the object :-)
A+
-- Jeanfrancois
>
> Many thanks to Alexey for considering most of the users' input in coming
> up with a good proposal of Grizzly 2.0
>
> -hg