I had the same idea as Trustin: a dedicated attribute storage per filter per
session, based on an IdentityHashMap.
I would definitely try to avoid numbering hell.
IoSession:
private IdentityHashMap <IoFilter, Map<String,Object>> ioFilterAttributes;
public Object getAttribute(IoFilter filter, String key) {
return ioFilterAttributes.get(filter).get(key);
}
Maarten
On 4/26/07, Mark Webb <[EMAIL PROTECTED]> wrote:
I think a numbering scheme could work. The
DefaultIoFilterChainBuilder class represents each filter with an index
internally already. Why not use a similar numbering scheme to order
the filters. It does not have to be 1,2,3. You could use 10,20,30 so
that if you wanted to insert a new filter between 10 and 20, you have
plenty of slots available. We could also expose a method that would
return a filter's id in the chain.
--
..Cheers
Mark
On 4/26/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> On 4/26/07, Mark Webb <[EMAIL PROTECTED]> wrote:
> > If the string manipulation/comparison/etc is a problem with using too
> > many CPU cycles, could we just just an int or long and give each
> > filter an id? This might also aid in the ordering.
> > The developer should always know the name or id of a filter, so it
> > should not make things any more complex.
>
> Well, using numbers might cause magic number hell. Is there any way
> to work around it?
>
> Just giving up storing stuff as session attributes and providing a
> dedicated attribute storage per filter per session might be a better
> choice. There are disadvantages in this approach. 1) JMX integration
> can be more complex because we have one more thing to wrap. 2) Any
> existing public session attribute keys that some IoFilters (e.g.
> SSLFilter) expose need to change somehow. I think these changes are
> not that hard to follow though.
>
> Once we make this change, the use of session attributes will decrease
> a lot, because a usual IoHandler implementor will define a class that
> stores the state of the session and store the instance of the class as
> a session attribute, like the following:
>
> public class ProtocolContext {
> public boolean userLoggedIn = false;
> public int userStateCode = 0;
> }
>
> public void sessionOpened(IoSession session) {
> session.setAttribute("ctx", new ProtocolContext());
> }
>
> public void messageReceived(IoSession session, Object message) {
> ProtocolContext ctx = (ProtocolContext) session.getAttribute("ctx");
> ....
> ctx.userStateCode = ...;
> }
>
> Then, what is the advantage of having session attributes over using
> multiton handlers? -- http://tinyurl.com/28j4oj
>
> I think we need to think again what session attributes are useful for
> if we are not going to use them to store filter states.
>
> Any idea?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
