Channel attachments?

[Marc-André Laverdière]

I just wanted to set a session ID to it and retrieve it later.
But got a null instead.

So I used a ChannelLocal...

I would've liked the attachment to just work... that I can retrieve a
session ID later down the line.

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/17 "이희승 (Trustin Lee)" <trustin at gmail.com>:
> Out of curiosity, what was your expectation?
>
> Thanks,
> Trustin
>
> On 06/17/2010 08:54 PM, Marc-André Laverdière wrote:
>> Hi Trustin,
>>
>> I don't think that ChannelLocal is THAT annoying. But its more related
>> to my experience that the attachment isn't working as one would
>> intuitively 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/17 "이희승 (Trustin Lee)" <trustin at gmail.com>:
>>> 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/
>>>
>>>
>>> _______________________________________________
>>> 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/
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>