You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Emmanuel Lecharny <el...@gmail.com> on 2011/07/01 01:13:22 UTC
Re: [MINA 3.0] Initial thoughts on FilterChain
On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>
>> <snip/>
>> This does meet some of our requirements, but not all. We can have something
>> similar to this and instead of returning true/false
>> from Filters, we can return the next step to be executed. Something like
>> this
>>
>> IoFilter messageReceived(IoSession session, Object message) {
>> // process
>>
>> // see if just to flow with Filter Chain
>> return null; // or something better
>>
>> // or
>> // a diff message detected, calculate next filter based on some app
>> specific state
>> return calculateNextFilter(state);
>> }
>>
>> command is passed back to the chain and it can take care of executing the
>> next filter.
>>
>> Shall try something similar in sandbox and lets see how it goes :)
> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
Not sure, Alan. There are some cases where it's mandatory that a filter
select the next filter to execute : for instance, if your codec produces
more than one message, and the following processing may depend on the
message type. Of course, you can use a demux protocol filter (I don't
exactly remember the name of it, so it's from the top of my head, but we
use such a mechanism in ADS), but it's just one option.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Julien Vermillard <jv...@gmail.com>.
On Fri, Jul 1, 2011 at 5:58 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jul 1, 2011, at 8:52 AM, Emmanuel Lecharny wrote:
>
>> On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
>>> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>>>> But all in all, in this case, the chain of filters will *be* a state machine.
>>> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
>>
>> Don't get me wrong... I'm not sure anyone here had in mind an implementation which picks the next filter randomly... Although, that could be funny :)
>
> To everyone but the person who has to debug what's going on. ;)
>
> With that said, why would we want our API make that possible? Would we not be doing our user base a service by switching the Mina API to a bona fide state machine with fixed state chains?
>
>
> Regards,
> Alan
>
Hi,
I think it's possible to make FilterChain a simple List of Filters
called by the chain and not-chained as we do.
For special usage where the Filter decide which filter to call, the
filter could be called from the "demuxing" filter :
http://s.apache.org/A9W
The chain could be stored in the IoService and copied to the session
only if it specifically was modified for this session (Copy on write).
It could save some memory.
Now the *REAL QUESTION* is how we implement SEDA/ExecutorFilter with
this kind of list of filter ?
Julien
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 1, 2011, at 8:52 AM, Emmanuel Lecharny wrote:
> On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
>> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>>> But all in all, in this case, the chain of filters will *be* a state machine.
>> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
>
> Don't get me wrong... I'm not sure anyone here had in mind an implementation which picks the next filter randomly... Although, that could be funny :)
To everyone but the person who has to debug what's going on. ;)
With that said, why would we want our API make that possible? Would we not be doing our user base a service by switching the Mina API to a bona fide state machine with fixed state chains?
Regards,
Alan
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 7/1/11 5:47 PM, Alan D. Cabrera wrote:
> On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
>> But all in all, in this case, the chain of filters will *be* a state machine.
> And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
Don't get me wrong... I'm not sure anyone here had in mind an
implementation which picks the next filter randomly... Although, that
could be funny :)
>> I have some ideas (and I even have created some branch years ago: http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play around this idea.
> I'll take a peek at these. Thanks!
frankly, those branches are mostly errands at this point. Don't expect
too much...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 1, 2011, at 8:04 AM, Emmanuel Lecharny wrote:
> On 7/1/11 4:59 PM, Alan D. Cabrera wrote:
>> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>>
>>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>>
>>>>> <snip/>
>>>>> This does meet some of our requirements, but not all. We can have something
>>>>> similar to this and instead of returning true/false
>>>>> from Filters, we can return the next step to be executed. Something like
>>>>> this
>>>>>
>>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>>> // process
>>>>>
>>>>> // see if just to flow with Filter Chain
>>>>> return null; // or something better
>>>>>
>>>>> // or
>>>>> // a diff message detected, calculate next filter based on some app
>>>>> specific state
>>>>> return calculateNextFilter(state);
>>>>> }
>>>>>
>>>>> command is passed back to the chain and it can take care of executing the
>>>>> next filter.
>>>>>
>>>>> Shall try something similar in sandbox and lets see how it goes :)
>>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>>
>> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
>
> Not necessarily. We can think about a multiple layer decoder which works the very same way.
I'm hearing possibility not necessity.
> But all in all, in this case, the chain of filters will *be* a state machine.
And here is my point. They all are really state machines. Having network protocols "randomly" choosing chain paths is an anti-pattern. State machines should be known and fixed at the time of protocol initiation.
> I have some ideas (and I even have created some branch years ago: http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play around this idea.
I'll take a peek at these. Thanks!
Regards,
Alan
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 7/1/11 4:59 PM, Alan D. Cabrera wrote:
> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>
>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>
>>>> <snip/>
>>>> This does meet some of our requirements, but not all. We can have something
>>>> similar to this and instead of returning true/false
>>>> from Filters, we can return the next step to be executed. Something like
>>>> this
>>>>
>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>> // process
>>>>
>>>> // see if just to flow with Filter Chain
>>>> return null; // or something better
>>>>
>>>> // or
>>>> // a diff message detected, calculate next filter based on some app
>>>> specific state
>>>> return calculateNextFilter(state);
>>>> }
>>>>
>>>> command is passed back to the chain and it can take care of executing the
>>>> next filter.
>>>>
>>>> Shall try something similar in sandbox and lets see how it goes :)
>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>
> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
Not necessarily. We can think about a multiple layer decoder which works
the very same way.
But all in all, in this case, the chain of filters will *be* a state
machine.
I have some ideas (and I even have created some branch years ago:
http://svn.apache.org/viewvc/mina/branches/mina-new-chain/ and
http://svn.apache.org/viewvc/mina/branches/mina-new-chain2/) to play
around this idea.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by Alex Karasulu <ak...@apache.org>.
On Fri, Jul 1, 2011 at 5:59 PM, Alan D. Cabrera <li...@toolazydogs.com> wrote:
>
> On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
>
>> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>>
>>>> <snip/>
>>
>>>> This does meet some of our requirements, but not all. We can have something
>>>> similar to this and instead of returning true/false
>>>> from Filters, we can return the next step to be executed. Something like
>>>> this
>>>>
>>>> IoFilter messageReceived(IoSession session, Object message) {
>>>> // process
>>>>
>>>> // see if just to flow with Filter Chain
>>>> return null; // or something better
>>>>
>>>> // or
>>>> // a diff message detected, calculate next filter based on some app
>>>> specific state
>>>> return calculateNextFilter(state);
>>>> }
>>>>
>>>> command is passed back to the chain and it can take care of executing the
>>>> next filter.
>>>>
>>>> Shall try something similar in sandbox and lets see how it goes :)
>>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>>
>> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
>
>
> I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
For simple cases this might "seem" like overkill but IMHO I think it's
better always to be explicit. It's clear what is happening. Surprise
Emmanuel that you did not jump for this you are Mr. State Machine :-).
Regards,
Alex
Re: [MINA 3.0] Initial thoughts on FilterChain
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jun 30, 2011, at 4:13 PM, Emmanuel Lecharny wrote:
> On 6/30/11 9:52 PM, Alan D. Cabrera wrote:
>> On Jun 30, 2011, at 2:42 AM, Ashish wrote:
>>
>>> <snip/>
>
>>> This does meet some of our requirements, but not all. We can have something
>>> similar to this and instead of returning true/false
>>> from Filters, we can return the next step to be executed. Something like
>>> this
>>>
>>> IoFilter messageReceived(IoSession session, Object message) {
>>> // process
>>>
>>> // see if just to flow with Filter Chain
>>> return null; // or something better
>>>
>>> // or
>>> // a diff message detected, calculate next filter based on some app
>>> specific state
>>> return calculateNextFilter(state);
>>> }
>>>
>>> command is passed back to the chain and it can take care of executing the
>>> next filter.
>>>
>>> Shall try something similar in sandbox and lets see how it goes :)
>> I'm not so sure that filters should be in charge of deciding who should be called next. I don't think that how the filter stack is assembled should be leaked into the filters themselves. The filter should be solely concerned with its task and not have to decide who gets called next.
>
> Not sure, Alan. There are some cases where it's mandatory that a filter select the next filter to execute : for instance, if your codec produces more than one message, and the following processing may depend on the message type. Of course, you can use a demux protocol filter (I don't exactly remember the name of it, so it's from the top of my head, but we use such a mechanism in ADS), but it's just one option.
I'm hearing a state machine that's implicitly defined via what gets returned by that method. If this is the case would it not be better to have an explicitly defined state machine?
Regards,
Alan