On 20/03/2019 10:07, Gordon Sim wrote:
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.
Fair enough.
I think I know how the software should be modified, then.
Thanks.
- Toralf
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
