Hi All,
Discovered an edge case in the messaging API that is causing me some
issues (Using qpid-0.28 on Centos 5.8).
It revolves around the reconnect functionality that is available on the
qpid::messaging::Connection class. This method is great as it enables
all the sessions associated with any active Senders/Receivers to get
reinitialized on a reconnect with a broker, without having to
close/delete the old Sessions, Senders or Receivers,and create new ones.
Not all my users use the 'reconnect' options on the connection class, so
I can just call the reconnect method manually when the application
discovers a disconnect has occurred. Which is great.
But one of my users has just discovered an edge case where the
connection can be active but the Session has had an error (i.e.
delivering a message to an already full queue). Under this condition
calling reconnect fails, quite rightly, because the connection is
already open. So I have an active connection but a Session in error. I
could call close on the connection, but this has the undesired effect of
closing all the active sessions, something I don't want to do. I would
like to just reset the error-ed Session, much like the reconnect method
achieves (it calls ConnectionImpl::resetSessions), but this
functionality is not directly available on the
qpid::messaging::Connection or qpid::messaging::Session classes.
Would this kind of Session reset functionality be made available in
future versions of qpid?
I was looking at patching my current qpid-0.28 source code to provide
this functionality, can any one think of a reason why exposing this
functionality might be a bad idea?
Any help/advice gratefully received.
Clive.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
