On 21/04/2020 22:31, Gordon Sim wrote:
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?
At the moment there are 39 connections and 59 connects have been logged,
so looks like the connection sometimes goes away. The process has been
active since 10 April. I think the connection went away more often in
the last version that had a shorter heartbeat interval, but it could be
a coincidence.
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?
I have no idea how to do that, I'm afraid. And the qpid-tool "help"
command does not really help.
[...]
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.
I still don't understand. I have 50 connections or whatever, and closing
one client socket makes all of them go away?
But maybe it's actually releasing process resources in general on exit
that does it.
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).
The close is supposed to be taken care of.
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.
That would explain it.
Maybe I'll have to bite the bullet and install a version that calls
close() on error. It might make everything clearer, at least.
- Toralf
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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
