Channel attachments?

["이희승 (Trustin Lee)"]

It does seem like that many people miss the session attributes in MINA. :)

I replaced session attributes with ChannelLocal because of efficiency
issues:

1) Session attributes require every channel has a hash map.  When there
are not many attributes, the hash map wastes memory.  By contrast,
ChannelLocal is much more memory efficient.

2) A user often uses a String as a session attribute key.  It's much
slower than ChannelLocal, which requires only identity comparison on
Channels.

3) ChannelLocal is type-safe (i.e. generics aware).

Also, I did not add an attribute map to ChannelHandlerContext and
instead stick to the attachment property because any state attached to
the context is not supposed to be accessed by others.  Moreover,
accessing many attributes requires many down-casts.  If there are many
state variables, I'd define a type with the multiple state variables and
store its instance as an attachment.

Is ChannelLocal really inconvenient when you have to maintain
per-channel state?  I'm not really sure yet, but please feel free to let
me know if you have a better idea.

Thanks!
Trustin

On 06/14/2010 11:34 PM, Marc-André Laverdière wrote:
> Yikes... that could turn to a maintainability pain. I personally
> prefer to write code that works no matter what happens to the
> pipeline.
> Still... should we have to rely on these various workarounds? Why
> can't attachments just _work_ as one would expect?
> 
> Marc-André LAVERDIÈRE
> "Perseverance must finish its work so that you may be mature and
> complete, not lacking anything." -James 1:4
> mlaverd.theunixplace.com/blog
> 
>  /"\
>  \ /    ASCII Ribbon Campaign
>   X      against HTML e-mail
>  / \
> 
> 
> 
> 2010/6/11 Jesse Hutton <jesse.hutton at gmail.com>:
>> On Fri, Jun 11, 2010 at 11:30 AM, Robert Wahlstedt <rob at isketch.net> wrote:
>>>
>>> On Jun 10, 2010, at 22:46 , blakeman8192 wrote:
>>>
>>>> I need a more elegant way to keep track of different objects (i.e. a
>>>> Player object) for a Channel.
>>>> Is this overlooked in the Netty design, or (more likely) am I missing
>>>> something?
>>>
>>> This is probably a very common functionality needed when building Netty
>>> based programs. More attention in the javadocs/documentation for best
>>> practices would be nice.
>>>
>>> I have solved it simply by subclassing DefaultChannelPipeline and putting
>>> the variables I need there. That way all of my handlers can access it by
>>> ChannelHandlerContext.getPipeline()
>>>
>>>
>>> /Rob
>>
>>
>> Just to add one more variation on the theme, my approach was to add whatever
>> state variables I needed to the final upstream handler in my pipeline
>> factory. Then, to get access I can do channel.getPipeline().getLast(),
>> casting it to the appropriate class.
>> Jesse
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100617/5388a095/attachment.bin