On 10/12/2020 09:36, Toralf Lund wrote:
On 09/12/2020 22:55, Gordon Sim wrote:
Does the queue depth on the queue(s) that the slow sends occur on ever
get large? (Is there some limit set on the queue depth?)
The queues are last-value queues sorted on the "subject" values. They
don't grow large, but obviously, some house-keeping is involved when
storing messages.
This leads to another question: When exactly does the broker acknowledge
message reception? Will it actually update queues first? I mean, it
might conceivably read the message, buffer it, acknowledge, then do the
routing.
The broker will only acknowledge the message once it has been
successfully enqueued on all relevant queues. If persistence is in use
then this will be once the journal has been updated on disk.
A last-value queue update involves dequeuing the old message that
matches the key then enqueuing the updated one.
Is the client on which you observe this the only one to publish to a
particular queue? (If not then it seems less likely that the queue is
the issue, if other clients never see such delays).
The only other thing I can think of that would cause the invocation of
send() to take a long time would be some sort of locking issue. Are
the multiple threads possibly sending concurrently?
There is another thread linked to QPid, but it takes care of
"request-response" messaging triggered by user actions. I can't see how
it would be active in all cases where I see delays.
But obviously, it seems quite likely that this is the case of a thread
waiting for *something*. Is there anything else that may somehow cause a
block?
The two things I can think of are waiting for a lock or waiting for
capacity. Waiting for capacity on 0-10 involves a session sync request.
If the session is in use by other threads that could include those other
operations as well.
Note that my application has extra threads that do unrelated
work. Also, I expect other threads started by the QPid library will be
active, as there is a receiver with a somewhat large capacity linked to
the same session. And my request-response thread will probably be
listening for incoming messages, too.
I should perhaps have mentioned that there is another problem that I
think may be related: It looks like heartbeat messages are also
sometimes delayed in a similar manner, unless they are lost completely.
Every few hours, I get a reconnect attempt during send or receive, even
though there is probably nothing wrong with the connection. That leads
to a "session busy" exception.
Is there anything different about the case where you see this? (I'm
assuming that not all clients have the same issue and that those that do
are the same ones i.e. on the same machines and with the same context).
If heartbeats are also delayed it seems to me less likely to be related
to the queue or the acknowledgements being delayed.
Again I wonder whether there is anything different about the
installation where this occurs?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
