On 07/23/2015 10:50 PM, Jakub Scholz wrote:
While playing with the AMQP 1.0 implementation in the C++ broker (0.32 &
0.34, both using Proton 0.9), I noticed some interesting points:
1) When tracing is switched on and AMQP 1.0 client connects with enabled
idle timeout, the broker properly logs the empty frames sent/received to
keep the connection alive. However the log file seems to contain empty line
after each received empty frame
I've fixed that: https://issues.apache.org/jira/browse/PROTON-962
2) When keeping the connection alive, the C++ broker seems to send the
empty frames always after half of the timeout specified when the connection
opened. The only exception is the first heartbeat, which is sent only after
the full timeout interval. In the log bellow, the idle timeout was set to
120 seconds - the broker sent the first after full 120 seconds, but the
subsequent only after 60 seconds:
[...]
This seems to be a bit strange, as I see no reason for the first heartbeat
to be sent later.
In both the broker and the client, qpid-cpp uses a timer task to ensure
that the tick is invoked on proton periodically. However when the
connection is opened the timer task is started before all the encoding
is done. Proton resets the time at which it needs to send a heartbeat
after it does any output which is after the task has been started. So
the first time the qpid-cpp timer task invokes the tick, it is a couple
of milliseconds too early, however it does not then call back to check
until the next interval.
(The design of proton fits more naturally with an io system where the
timeouts are managed by the poller, and the max wait time is retrieved
from proton and continually passed into the poll/select. Unfortunately
that would be a large and intrusive change for the qpid-cpp io layer,
hence the use of a periodic timer instead).
I can mitigate this by restarting the timer in qpid-cpp whenever it
encodes data. this avoids the initial longer gap.
3) Interestingly, the C++ client seems to approach the idle timeout
differently than the C++ broker and sends the empty frames only after the
full interval (as visible in the log above). Maybe it would be easier if
the broker and client approached the idle timeout in the same way.
The c++ client does do more or less the same thing (allowing for some
differences in threading). I don't see quite the same thing as you. I do
see the client occasionally 'missing' a heartbeat which makes it look
like it is using the longer interval, but for me this seems to be an
occasional occurrence.
I believe I have fixed these two anomalies:
https://issues.apache.org/jira/browse/QPID-6661
Obviously, these issues are not critical, they are more or less cosmetic
issues - do you think they are worth entering a JIRAs? I think that at
least the first point should be fixed, but to be honest I have no idea
whether it is an actual issue in the C++ broker / client or in the Proton
library, because I think the log message comes from Proton.
Thanks & Regards
Jakub
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
