On 20/03/2019 8:02 am, Toralf Lund wrote:
On 19/03/2019 22:07, Gordon Sim wrote:
On 19/03/2019 1:09 pm, Toralf Lund wrote:
Could that fit with what I'm seeing? Is there a chance that
Connection::isOpen() returns false after an error, yet the connection
isn't really released? How should I detect and handle that situation?
I'm not sure what you mean by 'really released'. The isOpen() returns
true if the AMQP connection is currently active, false otherwise.
The question is, when the connection is automatically closed on error,
is everything fully closed down in the same way as when calling
Connection::close()?
I've always assumed that close() would shut down all sessions and their
senders and receivers, but perhaps that's not the case?
That is the case; an explcit close() will indeed close and remove all
the sessions.
However if the connection is closed by the peer or there is a transport
error, then the sessions, though no longer actively open, will not be
removed from the connection. So on 'reanimating' it so to speak by
opening again, they will (I believe) be recreated. This is what the
reconnect feature is supposed to do, and open uses much of the same code
paths.
I suspect what may be happening is that when you open the same
connection that has been closed for some reason, if there were
previous sessions and consumers on it, those are recreated. If you
don't want that you can create a new connection instance before
opening it.
So closing does not make the existing sessions go away?
Actually, perhaps I've misunderstood the first sentence of the close()
documentation;
Closes a connection and all sessions associated with it. An opened
connection must be closed before the last handle is allowed to go
out of scope.
I've taken this to mean that I should create new sessions using
createSession() if I opened the connection again. Perhaps that's not the
case? Or is the morale of the story that I really ought not to call
open() a 2nd time?
If you want a 'fresh' connection, then I would create a new object and
open that as the simplest solution I think.
I notice that there is now also a reconnect(), but I
don't believe such a method existed at the time my application was written.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]