You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Trustin Lee <tr...@gmail.com> on 2007/04/25 11:13:48 UTC
Adding more than one filter of the same type.
Hi,
Current IoFilter implementations use session attributes to store their
internal data such as an event queue and buffers. Because the keys of
the internal data attributes are constant, it is impossible to add the
same IoFilter into one filter chain.
We could change the current filter implementations to use session
attributes with some common dynamic prefix. I think
"filter.<filterName>." will suffice. With this standardized scheme,
users will be able to add multiple filters (e.g. more than one
ProtocolCodecFilter) easily.
One problem is it involved String manipulation and therefore costs CPU
resource though.
WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Adding more than one filter of the same type.
Posted by Trustin Lee <tr...@gmail.com>.
On 4/26/07, Maarten Bosteels <mb...@gmail.com> wrote:
> 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);
> }
I had the same idea actually, using IdentityHashMap. :)
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Adding more than one filter of the same type.
Posted by Mark Webb <el...@gmail.com>.
fair enough. I think as long as there is some way to ensure that the
data in the IdentityHashMap is "live", we should be ok.
--
..Cheers
Mark
On 4/26/07, Maarten Bosteels <mb...@gmail.com> wrote:
> 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 <el...@gmail.com> 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 <tr...@gmail.com> wrote:
> > > On 4/26/07, Mark Webb <el...@gmail.com> 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
> > >
> >
>
Re: Adding more than one filter of the same type.
Posted by Maarten Bosteels <mb...@gmail.com>.
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 <el...@gmail.com> 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 <tr...@gmail.com> wrote:
> > On 4/26/07, Mark Webb <el...@gmail.com> 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
> >
>
Re: Adding more than one filter of the same type.
Posted by Mark Webb <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
> On 4/26/07, Mark Webb <el...@gmail.com> 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
>
Re: Adding more than one filter of the same type.
Posted by Trustin Lee <tr...@gmail.com>.
On 4/26/07, Mark Webb <el...@gmail.com> 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
Re: Adding more than one filter of the same type.
Posted by Mark Webb <el...@gmail.com>.
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.
On 4/25/07, Trustin Lee <tr...@gmail.com> wrote:
> Hi,
>
> Current IoFilter implementations use session attributes to store their
> internal data such as an event queue and buffers. Because the keys of
> the internal data attributes are constant, it is impossible to add the
> same IoFilter into one filter chain.
>
> We could change the current filter implementations to use session
> attributes with some common dynamic prefix. I think
> "filter.<filterName>." will suffice. With this standardized scheme,
> users will be able to add multiple filters (e.g. more than one
> ProtocolCodecFilter) easily.
>
> One problem is it involved String manipulation and therefore costs CPU
> resource though.
>
> WDYT?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
--
..Cheers
Mark
Re: Adding more than one filter of the same type.
Posted by Trustin Lee <tr...@gmail.com>.
On 4/30/07, Mark Webb <el...@gmail.com> wrote:
> what would the chain do if you add a filter with the same name as a
> filter already in the chain?
>
> 1. throw exception
> 2. not add the filter
> 3. overwrite the existing filter
> 4. have the chain rename the filter
It throws an exception. Filter name is an identifier.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Adding more than one filter of the same type.
Posted by Mark Webb <el...@gmail.com>.
what would the chain do if you add a filter with the same name as a
filter already in the chain?
1. throw exception
2. not add the filter
3. overwrite the existing filter
4. have the chain rename the filter
--
..Cheers
Mark
On 4/30/07, Trustin Lee <tr...@gmail.com> wrote:
> On 4/29/07, peter royal <pr...@apache.org> wrote:
> > On Apr 27, 2007, at 3:09 AM, Trustin Lee wrote:
> > > On 4/27/07, peter royal <pr...@apache.org> wrote:
> > >> Compute a static string upon class construction? append the class's
> > >> hashcode to the attribute? that should make it unique.
> > >
> > > We can do that if an IoFilter is supposed to belong to one session.
> > > That might make more sense because most filters needs to store some
> > > state. Is this what you thought?
> >
> > Maybe I'm confused on what's being solved.. But we want to be able to
> > add multiple instances of the same IoFilter class? One of ours that
> > uses fixed attribute names?
>
> Yes. All filters use fixed attribute names IIRC.
>
> > Since a class instance will only be in a single filter chain once
> > (even if its used for multiple sessions), if the filter appended a
> > number to its attributes, such as its hashcode, that'd provide
> > uniqueness?
>
> We might need to allow the same instance of IoFilter to be inserted
> more than once to one filter chain, which makes hashcode useless.
> Logging filter is a good example. A user can insert the same logging
> filter instance before and after the codec filter for debugging
> purpose.
>
> Hmmm... but just adding small restriction (i.e. no same filter
> instances in a chain) might make things much easier. :D
>
> WDYT?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
Re: Adding more than one filter of the same type.
Posted by peter royal <pr...@apache.org>.
On Apr 30, 2007, at 3:40 PM, Trustin Lee wrote:
>> Since a class instance will only be in a single filter chain once
>> (even if its used for multiple sessions), if the filter appended a
>> number to its attributes, such as its hashcode, that'd provide
>> uniqueness?
>
> We might need to allow the same instance of IoFilter to be inserted
> more than once to one filter chain, which makes hashcode useless.
> Logging filter is a good example. A user can insert the same logging
> filter instance before and after the codec filter for debugging
> purpose.
>
> Hmmm... but just adding small restriction (i.e. no same filter
> instances in a chain) might make things much easier. :D
>
> WDYT?
I think its fair to say that for our filters, if you want to use them
in a chain multiple times, you need unique instances.
I don't think it needs to be a general restriction for all filters..
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Adding more than one filter of the same type.
Posted by Trustin Lee <tr...@gmail.com>.
On 4/29/07, peter royal <pr...@apache.org> wrote:
> On Apr 27, 2007, at 3:09 AM, Trustin Lee wrote:
> > On 4/27/07, peter royal <pr...@apache.org> wrote:
> >> Compute a static string upon class construction? append the class's
> >> hashcode to the attribute? that should make it unique.
> >
> > We can do that if an IoFilter is supposed to belong to one session.
> > That might make more sense because most filters needs to store some
> > state. Is this what you thought?
>
> Maybe I'm confused on what's being solved.. But we want to be able to
> add multiple instances of the same IoFilter class? One of ours that
> uses fixed attribute names?
Yes. All filters use fixed attribute names IIRC.
> Since a class instance will only be in a single filter chain once
> (even if its used for multiple sessions), if the filter appended a
> number to its attributes, such as its hashcode, that'd provide
> uniqueness?
We might need to allow the same instance of IoFilter to be inserted
more than once to one filter chain, which makes hashcode useless.
Logging filter is a good example. A user can insert the same logging
filter instance before and after the codec filter for debugging
purpose.
Hmmm... but just adding small restriction (i.e. no same filter
instances in a chain) might make things much easier. :D
WDYT?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Adding more than one filter of the same type.
Posted by peter royal <pr...@apache.org>.
On Apr 27, 2007, at 3:09 AM, Trustin Lee wrote:
> On 4/27/07, peter royal <pr...@apache.org> wrote:
>> Compute a static string upon class construction? append the class's
>> hashcode to the attribute? that should make it unique.
>
> We can do that if an IoFilter is supposed to belong to one session.
> That might make more sense because most filters needs to store some
> state. Is this what you thought?
Maybe I'm confused on what's being solved.. But we want to be able to
add multiple instances of the same IoFilter class? One of ours that
uses fixed attribute names?
Since a class instance will only be in a single filter chain once
(even if its used for multiple sessions), if the filter appended a
number to its attributes, such as its hashcode, that'd provide
uniqueness?
-pete
--
proyal@apache.org - http://fotap.org/~osi
Re: Adding more than one filter of the same type.
Posted by Trustin Lee <tr...@gmail.com>.
On 4/27/07, peter royal <pr...@apache.org> wrote:
> On Apr 25, 2007, at 2:13 AM, Trustin Lee wrote:
> > Current IoFilter implementations use session attributes to store their
> > internal data such as an event queue and buffers. Because the keys of
> > the internal data attributes are constant, it is impossible to add the
> > same IoFilter into one filter chain.
> >
> > We could change the current filter implementations to use session
> > attributes with some common dynamic prefix. I think
> > "filter.<filterName>." will suffice. With this standardized scheme,
> > users will be able to add multiple filters (e.g. more than one
> > ProtocolCodecFilter) easily.
> >
> > One problem is it involved String manipulation and therefore costs CPU
> > resource though.
>
> Compute a static string upon class construction? append the class's
> hashcode to the attribute? that should make it unique.
We can do that if an IoFilter is supposed to belong to one session.
That might make more sense because most filters needs to store some
state. Is this what you thought?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: Adding more than one filter of the same type.
Posted by peter royal <pr...@apache.org>.
On Apr 25, 2007, at 2:13 AM, Trustin Lee wrote:
> Current IoFilter implementations use session attributes to store their
> internal data such as an event queue and buffers. Because the keys of
> the internal data attributes are constant, it is impossible to add the
> same IoFilter into one filter chain.
>
> We could change the current filter implementations to use session
> attributes with some common dynamic prefix. I think
> "filter.<filterName>." will suffice. With this standardized scheme,
> users will be able to add multiple filters (e.g. more than one
> ProtocolCodecFilter) easily.
>
> One problem is it involved String manipulation and therefore costs CPU
> resource though.
Compute a static string upon class construction? append the class's
hashcode to the attribute? that should make it unique.
-pete
--
proyal@apache.org - http://fotap.org/~osi