dev@grizzly.java.net

Re: [Fwd: [Issue 53] AttributeHolder needs maps with parameterized types <T>]

From: charlie hunt <charlie.hunt_at_sun.com>
Date: Mon, 18 Feb 2008 11:14:06 -0600

How about we add this to the Project Grizzly meeting agenda for Wednesday?

Or, do we believe we are arriving at a conclusion or decision on a
direction to go?

charlie ...


Oleksiy Stashok wrote:
> Hello Ken,
>
>>>>
>>>> Context... What would be the
>>>>> BEST to describe an attribute in a collection, in the context of
>>>>> grizzly's Context, SelectorHandler, Controller? does it really a
>>>>> String type? Actually, the way Grizzly using the *term* attribute
>>>>> is not even appropriate. Why? attribute is something that
>>>>> describes a specific distinguishable feature of the particular
>>>>> object (or instance). The way grizzly uses here is, to store SOME
>>>>> objects and their references, in case it needs at various scopes.
>>>>> This forces users to "create" their own strings?keys (to
>>>>> accommodate in) to retrieve the references.
>>>>
>>>> Right. Might not be perfect, but a lot of API use that approach:
>>>>
>>>> http://java.sun.com/j2se/1.4.2/docs/api/javax/net/ssl/SSLSession.html
>>>> http://java.sun.com/javaee/5/docs/api/javax/servlet/ServletContext.html
>>>>
>> And all of them suffer a string hash lookup on every attribute
>> access. That is a String hash computation
>> and comparison, and these are expensive operations to perform
>> (possibly multiple times) every time we
>> read bytes from a channel.
> Hashcode computation happens just once for String, though comparison
> could be expensive.
>
>> The design tradeoff here is that there should only be a small number
>> of unique attributes in the system, so that the
>> AttributedObject arraylists are not too large (say 10-30 attributes,
>> not hundreds). Many other designs are possible,
>> depending on exactly how a Map<Integer,Object> is implemented, with
>> the assumption that the keys are small contiguously
>> allocated non-negative integers. For example, segmented maps could
>> be used, but then the lookup cost is higher.
>> Saving space costs time in this case.
> I like your implementation! Agree, we can have several
> "AttributeObjectBase"-like implementation, one you have in Corba with
> ArrayLists, another with Maps for situation, where we can have more
> attributes.
> Not sure we need to store type in Attribute? Which role does it play?
>
> But in common I like idea very much!
>
> Thanks.
>
> WBR,
> Alexey.
>
>>
>> Ken.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net For
>> additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>