On 18/12/2019 12:33 pm, Toralf Lund wrote:
I get the exact behaviour I'm seeing now only in a version that was
deployed about a week ago, and since then, between 60 and 70
session-busy exceptions have been registered. Most of these came from
Session::nextReceiver() or Receiver::fetch(), but exactly 2 were raised
by Sender::send(). In both these cases, the application locked up more
or less directly - the session error was at least the last item logged
when the process was in the locked state. It has not got stuck in any
other situations.
Due to the way exception handling is implemented, there is a chance that
there is another attempt at sending data after an exception from
Sender::send(), without resetting the session or anything. On the other
hand, a receive/nextReceiver() exception is in practice always followed
directly by
if(session.isValid() && session.hasError()) {
Util::debug(1, "Reset AMQP session with error...");
session.close();
session=qpid::messaging::Session();
}
The same code is also executed eventually in the send case, but there
may be other intervening Sender::send() calls, and also operations like
Session::getSender() or even (at least in theory) Session::createSender().
Do multiple threads use the session concurrently (wondering if it is
possible that the session is deleted while a send call is in progress)?
I think for the 'locking up' some pstack output would be useful. For the
extra connections, some more logging if possible.
I can't see anything that would obviously cause a lock up in the send,
and if it is a heartbeat timeout that causes the reconnect I would
expect the socket to be closed.
Sorry we could not be more help at this point.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
