I have re-read the source code and I found some
bad reading from my first thought.
First in messageReceived, it only goes to the
next filter only if it is not a keep alive message,
so it is perfectly OK.
In sessionIdle, it really passes every idle status
to the next filter, whatever the KeepAliveFilter does.
I think this should not be. I believe it should go
to the next filter only if it was not catch by the K-A-filter.
Now on the logic of this filter, I believe it is perfectly ok for
a ping-pong behaviour, but not in "Deaf Speaker" mode.
Indeed in Deaf Speaker mode, it only sends a ping message
and never receives a pong so the READER_IDLE is not
clear, but it should since I feel like the spirit of this filter
is to clear it.
Also what about the WRITER_IDLE or BOTH_IDLE ?
This filter will never catch it...
For the "next filter" case, I would suggest the following (I have not tested it
though...)
in sessionIdle
public void sessionIdle(
NextFilter nextFilter, IoSession session, IdleStatus status) throws
Exception {
try {
...
} finally {
if (status != IdleStatus.READER_IDLE) {// only if not READER_IDLE
nextFilter.sessionIdle(session, status);
}
}
}
For BOTH_IDLE, does the IdleStatus contains READ_IDLE ?
If not, should all tests about READ_IDLE be with BOTH_IDLE ?
For WRITE_IDLE, I don't know if it is relevant.
If so, then I would suggest to make two kind of filter, one for READ_IDLE
and another one for WRITER_IDLE, so the user can choose one or the other
or both.
Now on the "Deaf Speaker" mode issue, I don't know how in Mina
we can "clear" the Idle (in this case the READ_IDLE) ?
So I would suggest, if it is not possible, to say in the API doc something
about this limitation (if there is one of course, I can be completely wrong ;-)
Frederic
----- Original Message -----
Sent: Thursday, March 13, 2008 7:55 AM
Subject: Keep Alive Filter question
Hi Mina,
I am currently starting a new frame of benchmark using
Mina in version 2. I surely will come back with some questions
and of course some feed back during this period.
My question today is about the Keep Alive filter in Mina core.
I decide that it could be useful for some client to have this
feature enabled, and I try to find what to do exactly.
I choose that the server part will never be the source of
a Keep Alive request, since it should be (for my case)
the client that is responsible to ensure its connection.
The server must only respond to the client, no more.
I try two options (describe in API page of the filter) :
- the client is in Deaf Speaker mode :
When idle status is raised, it sends a keep alive ping message
but does not wait for the pong message from the server,
so clear the idle status immeditaly.
The policy is in OFF mode like the API says.
- the client is in active mode :
When idle status is raised, it sends a keep alive ping message
and waits for the pong message from the server to clear the idle status.
The first option is obviously less network consumming, that's why
I try to use it first. So I made a simple modification in one of my client
to check the behaviour by including a sleep(long time) between
the connection process and the first message to be sent to the server.
What I observed is the following :
- in Deaf Speaker mode : 50s of request interval, 190s of sleep
Only one Keep Alive message is sent after the first 50s after
the connection is opened, nothing after.
Is this normal behaviour ?
- in Active mode : same 50s of request interval, 190s of sleep
Every 50s after the connection is opened, a K-A message
is sent and an acknowledge from the server is received.
Correct behaviour.
It seems like in Deaf Speaker mode, the idle is only processed one
time. It seems logic since in this mode, only one message is sent
and the Keep Alive filter only trap idle in read part, not write part.
Am I correct if I say that to be functionnal the Keep Alive filter
should trap write idle too in Deaf Speaker mode or it will only
trap the read idle once and no more (except of course if new
messages are received) ?
Also one question on implementation :
In messageReceived and sessionIdle methods, there are a try-finally
block that always passed to the next filter the received or idle status.
Is this correct ?
Should the filter stop the filter chain when the message received is
truely a request or answear of K-A filter ?
Same on Idle, when it is processed by the K-A filter, should it be
forwarded to the next filter (and therefore generating some idle
method on other parts which is probably not wanted except
if the answear never comes back) ?
Again, thank for the great job !
Frederic
