[About the Filter Chain] Events

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

as I'm looking deeply into the impact on the code of the new chain 
proposals, I'm looking at the events we are handling.

In the following list, I have sorted all the events in two categories : 
incoming and outgoing events. Incoming events are those received from 
the clients, outgoing events are those emitted by the server.

Here is the list of those events :

SESSION_CREATED : An incoming event.
SESSION_OPENED : Seems to me to be a duplication of the previous event. 
An incoming event.
SESSION_CLOSED : An incoming event.
MESSAGE_RECEIVED : Clearly an incoming event.
MESSAGE_SENT : IMHO, useless. Must disappear.
SESSION_IDLE : Questionable. But if we keep it, should be considered as 
an incoming event.
EXCEPTION_CAUGHT : Interesting ... IMO, an incoming event too. Even if 
generated during a write operation (or while processing a Write event), 
it's applied to the session.incomingChain so that all the filters can 
handle it. The question is : should we also propagate this event through 
the outgoingChain ?
WRITE : Outgoing event.
CLOSE : Not sure what this event is used for. We already have a 
SESSION_CLOSED, I'm wondering if it's not a duplication.
SET_TRAFFIC_MASK : Seems to be used nowhere. It appears to have been 
created to handle custom events. I suggest that we ignore this event, 
unless someone has a clear vision on how to use it and why.

Did I forgot anything important?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: IdleStatusCheker, Was : Re: [About the Filter Chain] Events

[Julien Vermillard <jv...@archean.fr>]

On Wed, 05 Nov 2008 12:17:03 +0100
Emmanuel Lecharny <el...@gmail.com> wrote:

> Julien Vermillard wrote:
> > session idleing is usefull and well triggered using select(1000)
> > timeout in AbstractPollingIoProcessor internals.
> >   
> Except that discovering such magic number (1000) in the code is
> pretty embarrassing ... For a heartbeat system, this is certainly not
> what we could expect the code to be :)
> 
> But, basically, yes, if we can add a configurable parameter to be
> used in the select(), that would do the trick.
> 
> Now, should we modify the NioProcessor thread to handle such a case, 
> when it can be done in a filter? I think that it should be a
> combinaison : a select() with a configurable value (ie, not
> necessarily something which has to be set from the outside, but a
> value which can be set by a filter), and a filter to handle such an
> heartbeat, with a specific message sent to the chain (HeartBeatEvent).
> 
> Just pushing ideas here ...
> 
Actually the idle event for session is quite simple and work well, you
got it with a granularity of 1 sec without extract polling thread. What
is more questionable is the ioService idle event who use an external
polling thread (IdleStatusCheker).

Throughput calculation is an issue too because it's done in some kind
of very intrusive way.

Changing the select timeout is an idea, perhaps we can find a way to
automagically set it to the minimun of idle time of all the sessions
managed by the IoP. If the mnimum idle time is 10 seconds, why check
every seconds ? but it's some kind of tuning and out-of-radar for
today :)

Julien

Re: IdleStatusCheker, Was : Re: [About the Filter Chain] Events

[Emmanuel Lecharny <el...@gmail.com>]

Julien Vermillard wrote:
> session idleing is usefull and well triggered using select(1000)
> timeout in AbstractPollingIoProcessor internals.
>   
Except that discovering such magic number (1000) in the code is pretty 
embarrassing ... For a heartbeat system, this is certainly not what we 
could expect the code to be :)

But, basically, yes, if we can add a configurable parameter to be used 
in the select(), that would do the trick.

Now, should we modify the NioProcessor thread to handle such a case, 
when it can be done in a filter? I think that it should be a combinaison 
: a select() with a configurable value (ie, not necessarily something 
which has to be set from the outside, but a value which can be set by a 
filter), and a filter to handle such an heartbeat, with a specific 
message sent to the chain (HeartBeatEvent).

Just pushing ideas here ...

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: IdleStatusCheker, Was : Re: [About the Filter Chain] Events

[Julien Vermillard <jv...@archean.fr>]

session idleing is usefull and well triggered using select(1000)
timeout in AbstractPollingIoProcessor internals.

It's service idleing the problem, you can listen an IoService (not a
session) for Idleing.

On Wed, 05 Nov 2008 19:57:04 +1000
Brad Harvey <ha...@gmail.com> wrote:

> Hi,
> 
> Are session idle notifications useful for implementing heartbeat 
> processing?  I'm thinking of protocols with complicated session
> layers (eg FIX) that might be nice to implement in filters.
> 
> Having said that, it should be feasible to insert a filter that keeps 
> track of activity (or lack of it) when needed. 
> 
> Brad.
> 
> Julien Vermillard wrote:
> > 2) check IoService idleing. Funny I didn't know this feature. You
> > can listen an IoService for idleing. I really wonder who use that.
> >
> >
> >   

Re: IdleStatusCheker, Was : Re: [About the Filter Chain] Events

[Brad Harvey <ha...@gmail.com>]

Hi,

Are session idle notifications useful for implementing heartbeat 
processing?  I'm thinking of protocols with complicated session layers 
(eg FIX) that might be nice to implement in filters.

Having said that, it should be feasible to insert a filter that keeps 
track of activity (or lack of it) when needed. 

Brad.

Julien Vermillard wrote:
> 2) check IoService idleing. Funny I didn't know this feature. You
> can listen an IoService for idleing. I really wonder who use that.
>
>
>   

IdleStatusCheker, Was : Re: [About the Filter Chain] Events

[Julien Vermillard <jv...@archean.fr>]

On Tue, 04 Nov 2008 17:57:55 +0100
Emmanuel Lecharny <el...@gmail.com> wrote:

> Maarten Bosteels wrote:
> > Hello,
> >   
> Hi Maarten (eh eh, I typed it correctly this time !),
> > I also use messageSent but I guess I can also replace it with an
> > IoFutureListener.
> >
> > What do you mean when you say that SESSION_IDLE is questionable ?
> > What would you replace it with ?
> >   
> There is a thread which looks for sessions in idle state, in order to 
> kill them after a certain period of time (a timeout). So my question
> is why do we have to deal with a sessionIdle message ? And when is it 
> generated ? I'm missing something in this area.
> > My guts feeling is that exceptionCaught should also be propagated
> > to the outgoing chain...
> > but right now I have no examples to back up that feeling.
> >   
> I have to go deeper into it, too.
> 
> Thanks Maarten !
> 

Ok yesterday night, I drank some Armagnac, removed by brain and started
to try to understand why the hell the IdleStatusChecker is dealing with
polled transport who are triggering idle events on select()/poll()
timeout.

IdleStatusChecker is (ab)used for :

1) the most obvious case, checking for IDLE event every 1 second on
transport who can't do select() timeouting or are blocking, so they need
another task for doing it (VmPipe, SerialTransport).

At the origin it was the only usage, and was a class dedicated to
VmPipe until I extract it and generalized for using it with
SerialTransport (it was called VmPipeIdleStatusChecker).

I was quite surprised when Emm said me it was used with Nio based
transports, so I discovered the other new usages : 

2) check IoService idleing. Funny I didn't know this feature. You
can listen an IoService for idleing. I really wonder who use that.

3) Because in the code editor, there was some free space for more
bloat/code, it's used for update throughput stats (yes an IdleChecker
dealing with throughput).Cause it was easier to plug stats there,
because it was already a task running every 1 seconds.

I think it need to serious rework, for make it understandable without
usage of doping drinks.

Julien

Julien
Julien

Re: [About the Filter Chain] Events

[Emmanuel Lecharny <el...@gmail.com>]

Maarten Bosteels wrote:
> Hello,
>   
Hi Maarten (eh eh, I typed it correctly this time !),
> I also use messageSent but I guess I can also replace it with an
> IoFutureListener.
>
> What do you mean when you say that SESSION_IDLE is questionable ?
> What would you replace it with ?
>   
There is a thread which looks for sessions in idle state, in order to 
kill them after a certain period of time (a timeout). So my question is 
why do we have to deal with a sessionIdle message ? And when is it 
generated ? I'm missing something in this area.
> My guts feeling is that exceptionCaught should also be propagated to the
> outgoing chain...
> but right now I have no examples to back up that feeling.
>   
I have to go deeper into it, too.

Thanks Maarten !

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [About the Filter Chain] Events

[Maarten Bosteels <mb...@gmail.com>]

Hello,

I also use messageSent but I guess I can also replace it with an
IoFutureListener.

What do you mean when you say that SESSION_IDLE is questionable ?
What would you replace it with ?

My guts feeling is that exceptionCaught should also be propagated to the
outgoing chain...
but right now I have no examples to back up that feeling.

Maarten

On Mon, Nov 3, 2008 at 4:29 PM, Mark Webb <el...@gmail.com> wrote:

> I had logic in my IoHandler that was quite complex and there were 3
> different parts of the code that could send data back to the client.
> Instead of placing a WriteFuture in all 3 places, I put the logic in
> messageSent.
>
> I could just define an IoFutureListener that is passed into all 3
> WriteFuture's though.  If it makes our lives (as API developers)
> easier, then I can change my code (as an end user).
>
> --Mark
>
>
> On Mon, Nov 3, 2008 at 10:13 AM, Emmanuel Lecharny <el...@gmail.com>
> wrote:
> > Mark Webb wrote:
> >>
> >> I have used MESSAGE_SENT, not sure I agree that it should disappear.
> >>
> >
> > May I ask you in which context you used it ? I'm wondering if we can
> cover
> > your case with WriteFuture ?
> >
> >> What about situations where MINA is used in a client library?  Won't
> >> much of your list be reversed?
> >>
> >
> > That's a very good question ! I don't think it makes any difference. From
> > the client side, the incoming events are generated by an outgoing event
> on
> > the server side. Ie, the server write a response, then the client get a
> > MESSAGE_RECEIVED event to deal with. In fact, it's really like if you
> have
> > nothing in between the client and the server. The client write a message,
> > the server read it, then the server write the response, the client read
> it.
> >
> > If you take the protocolCodecFilter, it works the same for the server and
> > the client. A message will have to be encoded in both case when writing
> the
> > message (and it's always on the outgoing chain), and decoded when read
> > (incoming chain).
> >
> > I may miss something, but AFAICS, it's absolutely symetric.
> >
> > --
> > --
> > cordialement, regards,
> > Emmanuel Lécharny
> > www.iktek.com
> > directory.apache.org
> >
> >
> >
>

Re: [About the Filter Chain] Events

[Mark Webb <el...@gmail.com>]

I had logic in my IoHandler that was quite complex and there were 3
different parts of the code that could send data back to the client.
Instead of placing a WriteFuture in all 3 places, I put the logic in
messageSent.

I could just define an IoFutureListener that is passed into all 3
WriteFuture's though.  If it makes our lives (as API developers)
easier, then I can change my code (as an end user).

--Mark


On Mon, Nov 3, 2008 at 10:13 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Mark Webb wrote:
>>
>> I have used MESSAGE_SENT, not sure I agree that it should disappear.
>>
>
> May I ask you in which context you used it ? I'm wondering if we can cover
> your case with WriteFuture ?
>
>> What about situations where MINA is used in a client library?  Won't
>> much of your list be reversed?
>>
>
> That's a very good question ! I don't think it makes any difference. From
> the client side, the incoming events are generated by an outgoing event on
> the server side. Ie, the server write a response, then the client get a
> MESSAGE_RECEIVED event to deal with. In fact, it's really like if you have
> nothing in between the client and the server. The client write a message,
> the server read it, then the server write the response, the client read it.
>
> If you take the protocolCodecFilter, it works the same for the server and
> the client. A message will have to be encoded in both case when writing the
> message (and it's always on the outgoing chain), and decoded when read
> (incoming chain).
>
> I may miss something, but AFAICS, it's absolutely symetric.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Re: [About the Filter Chain] Events

[Emmanuel Lecharny <el...@gmail.com>]

Mark Webb wrote:
> I have used MESSAGE_SENT, not sure I agree that it should disappear.
>   
May I ask you in which context you used it ? I'm wondering if we can 
cover your case with WriteFuture ?

> What about situations where MINA is used in a client library?  Won't
> much of your list be reversed?
>   
That's a very good question ! I don't think it makes any difference. 
 From the client side, the incoming events are generated by an outgoing 
event on the server side. Ie, the server write a response, then the 
client get a MESSAGE_RECEIVED event to deal with. In fact, it's really 
like if you have nothing in between the client and the server. The 
client write a message, the server read it, then the server write the 
response, the client read it.

If you take the protocolCodecFilter, it works the same for the server 
and the client. A message will have to be encoded in both case when 
writing the message (and it's always on the outgoing chain), and decoded 
when read (incoming chain).

I may miss something, but AFAICS, it's absolutely symetric.

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: [About the Filter Chain] Events

[Mark Webb <el...@gmail.com>]

I have used MESSAGE_SENT, not sure I agree that it should disappear.

What about situations where MINA is used in a client library?  Won't
much of your list be reversed?



On Mon, Nov 3, 2008 at 9:41 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> as I'm looking deeply into the impact on the code of the new chain
> proposals, I'm looking at the events we are handling.
>
> In the following list, I have sorted all the events in two categories :
> incoming and outgoing events. Incoming events are those received from the
> clients, outgoing events are those emitted by the server.
>
> Here is the list of those events :
>
> SESSION_CREATED : An incoming event.
> SESSION_OPENED : Seems to me to be a duplication of the previous event. An
> incoming event.
> SESSION_CLOSED : An incoming event.
> MESSAGE_RECEIVED : Clearly an incoming event.
> MESSAGE_SENT : IMHO, useless. Must disappear.
> SESSION_IDLE : Questionable. But if we keep it, should be considered as an
> incoming event.
> EXCEPTION_CAUGHT : Interesting ... IMO, an incoming event too. Even if
> generated during a write operation (or while processing a Write event), it's
> applied to the session.incomingChain so that all the filters can handle it.
> The question is : should we also propagate this event through the
> outgoingChain ?
> WRITE : Outgoing event.
> CLOSE : Not sure what this event is used for. We already have a
> SESSION_CLOSED, I'm wondering if it's not a duplication.
> SET_TRAFFIC_MASK : Seems to be used nowhere. It appears to have been created
> to handle custom events. I suggest that we ignore this event, unless someone
> has a clear vision on how to use it and why.
>
> Did I forgot anything important?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>