On 19/05/16 13:47, Michal Zerola wrote:
Hi Gordon,
yes, it looks exactly like the issue described in QPID-4524. It seems
strange to me that the issue was closed with a statement - expected
behavior. I have increased the sync_op_timeout to 5 minutes, but it just
delayed the same error on the client. It is also not a store performance
problem, since I can send 300 messages (all 1MB size) using C++ client in
under a minute without any problem (using async sender). I am attaching logs
again.
Yes, the performance you observe from c++ and the fact that even 5
minutes is timing out suggests there is some problem here.
One more config suggestion if you don't mind... can you try increasing
qpid.session.byte_limit? The default value seems to be 1M which I think
may be significant here.
nosync_6.log <http://qpid.2158936.n2.nabble.com/file/n7644270/nosync_6.log>
This trace looks different from the last one. The transfer is sent
followed by a flush. The broker responds to the flush immediately as
expected, but does has not confirmed the transfer yet. The client then
*waits* for 5 minutes before sending the next flush. The broker responds
to the flush immediately, at this time confirming that the message was
indeed completed. The client then immediately issues a sync, which again
the broker replies to immediately indicating that all is completed. The
client then still times out.
So (a) why is the client not sending flushes more regularly and (b) why
when it does actually get confirmation for both of its last two attempts
to flush and sync respectively does it still timeout?
nosync_cpp.log
<http://qpid.2158936.n2.nabble.com/file/n7644270/nosync_cpp.log>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
