On 28/03/2019 15:56, Toralf Lund wrote:
Hi,
I have another question related to my recent post about trying to
re-establish lost connections. Recall that my system is set up without
automatic reconnect, but may do a "manual reconnect" via
qpid::Messaging connection(url);
...
if(!connection.isOpen()) {
connection.open();
}
and that this is sometimes triggered by an "internal disconnect"
accompanied by an exception with message "Failed to connect (reconnect
disabled)".
Now, I just found that some of the reconnects are accompanied by a
"Session detached by peer" exception. I'm struggling a bit to find out
what exactly triggers this; the problems occur once every few hours at
a remote site, and I can't just start or stop or update the software
at any old time, so it's a bit hard to debug...
I just noticed that the broker log has something like
2019-04-01 11:11:42 [Broker] error Channel exception: session-busy:
Session already attached:
anonymous.c9a1f4cf-7427-4e77-8870-e118b099c6da
(/work/build/rpmbuild/BUILD/msat-qpid-cpp-1.36/msat-qpid-cpp-1.36.0/src/qpid/broker/SessionManager.cpp:55)
2019-04-01 11:11:46 [Protocol] error Connection
qpid.10.31.193.215:5672-10.31.192.61:35954 timed out: closing
for most or all the reconnects. The first time-stamp seems to correspond
to the connection open and "Session detached by peer" exception.
Perhaps this means the broker still thinks the old connection is open,
even though the client considers it as lost? And maybe the attempt to
re-establish/re-use the old session with the new connection fails as a
result of that?
My question is: Is there a chance that the above open() might trigger
this exception as it tries to re-establish a session that was there
before the disconnect? If that's the case, is there a way I can avoid
getting into the situation? Would it help to do something like
if(session.isValid() && session.hasError()) {
session.close();
}
first? (Where "session" represents the session associated with
"connection" - there is one at the most.)
Thanks,
- Toralf
