On 20/04/2020 12:28 pm, Toralf Lund wrote:
On 16/04/2020 18:00, Gordon Sim wrote:
On 16/04/2020 12:24 pm, Toralf Lund wrote:
It turns out that addition of new connections coincide with log
message like
2020-04-15 09:10:25 [Client] info Trying to connect to cirm...
2020-04-15 09:10:25 [System] info Connecting: 10.0.1.215:5672
2020-04-15 09:10:25 [Client] info Connection
[10.0.2.61:37576-cirm:5672] connected to tcp:cirm:5672
2020-04-15 09:10:25 [Client] info Connected to cirm
2020-04-15 09:10:25 [Client] error session-busy: Session detached by
peer
This is from "info+" logging by the QPid library; date and time is
added by a log handler in the application. This sequence of events is
triggered by Sender::send() or Receiver::receive(), i.e. we're
looking at an automatic reconnect.
Are there errors showing disconnection that triggers the reconnect?
Any indication of what exactly the error was that triggered it? Are
there any heartbeat related errors on either client or server for
example?
On the client side, the only qpid log messages I can find are the ones
shown above.
How many of the 'Trying to connect' messages are there and how does that
compare to the number of stale connections?
The server log has a number of entries like
Channel exception: session-busy: Session already attached:
anonymous.959cc402-7ba5-4865-830a-f850a57356f7
which are typically followed by
Connection ... timed out: closing
I wonder if you can close the connections using qpid-tool, and what
happens on the client process if you do so?
[...]
Also, surely there can't be communication issues at this stage, as
then the entire reconnect operation would have failed? Or am I
missing something?
And more importantly: Is there anything I can do to make the "stale"
connections go away? My strategy for recovering from the error is simply
qpid::Messaging::Session session;
qpid::Messaging::Connection connection;
....
session.close();
session=connection.createSession();
But evidently, that's not enough.
The connections disappear if I restart the application, so I suspect
connection.close() ; connection.open(); would help, but if that's the
case, why? How is what it does different from closing the one and
only session?
Closing the last session will not automatically close the connection.
So again, what exactly does Connection::close(), or alternatively the
Connection destructor, or something else that happens on exit, do to
make the connections go away?
Connection close will close the TCP socket. If there are active
sessions, it will first close those.
The destructor of a Connection object will *not* call close however.
There was some discussions of this many years ago and the concern was
that close can fail and might cause problems in destructors. (You can of
course still create some scoped object to automatically close
connections if wanted).
It feels a bit like somehow there are connections being leaked without
being closed. However I can't see how that could happen for the built in
reconnect as that never creates connection objects.
The other possibility is that the socket somehow is not closed even
though reconnect is triggered, but again, I can't see how that could happen.
It seems quite clear that *all*
connections are removed, not just the one from the last reconnect.
However creating a new session on the same connection should not then
cause a new connection to be opened.
So other than the original open(), there is nowhere in your
application that a new connection would be created other the reconnect
logic?
I'm quite sure there isn't.
Also, I don't ever see extra connections unless there is a reconnect
message as indicated.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
