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
