On 27/04/2020 10:40, Toralf Lund wrote:
On 22/04/2020 16:24, Gordon Sim wrote:
On 22/04/2020 2:57 pm, Toralf Lund wrote:
On 21/04/2020 22:31, Gordon Sim wrote:
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.
How many 'timed out' errors do you have in the server logs?
Well, I've lost track every so slightly now because stuff has happened
in the mean time, but I think there might be a "timed out" error for
every connect.
I just did a restart, and noticed something interesting:
# grep 10.0.1.61:37836 /var/log/qpidd.log
2020-04-26 12:56:14 [Protocol] error Connection
qpid.10.0.2.215:5672-10.0.1.61:37836 timed out: closing
2020-04-27 08:07:11 [System] warning CLOSING
[qpid.10.0.2.215:5672-10.0.1.61:37836] unsent data (probably due to
client disconnect)
10.0.2.215:5672-10.0.1.61:37836 was one of the "extra" connections
that were listed by qpid-stat -c before the restart. The client had
logged a reconnect + session-busy at Apr 26 12:56:03
I saw something similar for all the stale connections that were there
at this point. (Not that many as there was another restart a few days
ago.)
[...]
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.
Run qpid-tool with appropriate url to broker. Then type `schema` and
repeat until it returns the schema (its not a very polished tool I'm
afraid). The do `list connections` and look for one of the stale
connections. Then do `call <id> close` where <id> is the connection
id of one of the stale connections.
OK.
I'll try that when I have a connection to test on. There is nothing
right now because I did the restart test (see above) before I read
this...
Tried this now. The client application reported nothing out of the
ordinary, and there wasn't anything in the server logs. Unfortunately,
the connection didn't go way either - it was still listed by qpid-tool
and qpid-stat -c.
qpid-tool seemed to think the close was successful - it said
qpid: call 244 close
qpid: OK (0) - {}
- Toralf
(https://urldefense.proofpoint.com/v2/url?u=https-3A__qpid.apache.org_releases_qpid-2Dcpp-2D1.39.0_cpp-2Dbroker_book_chapter-2DManaging-2DCPP-2DBroker.html-23MgmtC-2D2B-2D2B-2DUsingqpidtool&d=DwICaQ&c=KV_I7O14pmwRcmAVyJ1eg4Jwb8Y2JAxuL5YgMGHpjcQ&r=Q0oqxzgUp3xCCIiJDwS-RbNDndQ-KZDhj8wwveNoqU4&m=xwGaJiTNG_9qi1Tc-UTQgUg66aroKEPCWThjXrZ6cgo&s=MPhQ3ABns4D_F9zPJ1Y4zHgfRAB-IR1lryrqxpzox0U&e=
)
[...]
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?
No, there is a one-to-one relationship between connections and
sockets at any time. (A connection that reconnects will create a new
socket for the same connection object, but that should only ever
happen when the previous socket ended).
Sessions are multiplexed conversations over a connection. There is
generally at least one session on a connection, as everything you
want to do with a connection requires a session (e.g. send messages,
subscribe etc).
OK.
Thanks.
- Toralf
---------------------------------------------------------------------
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
