Shan Wang wrote:
I fixed it by adding session.close() before calling
FailoverManager::connect() again after disconnect. So it seems the
resource leaked was from uncleaned sessions. I forgot to mention this
problem only affects Windows client.
Ok, glad you got it fixed though it sounds like there may be some fix
also required in the windows client side IO(?).
Besides, on windows I can call
session.close() without having the session binding with any connection(
I mean creating a session object but haven't called
connect().newSession() ), but on Linux this will cause a crash, the
cause seems to be from the mutex the session is using.
What version are you using? Invoking close on an invalid session (i.e.
one not returned by newSession()) should no longer result in an error.
Invoking other methods will do however.
Another question is, what the FailoverManager does when the current
connection becomes unavailable? As I understand it, FailoverManager will
try to reconnect once according to the policy specified and if failed it
will set the state to CAN'T CONNECT and give up. So if my cluster has
two brokers and both of them are out of reach, am I right that client
application has to reconnect by calling
FailoverManager::connect()explicitly?
Yes, that is right.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
