Gordon,
Thanks for the quick reply.
Basically, the session is being used by several other senders/receivers,
so just being able to reset the session saves a lot of hassle. My patch
was to add a resetSessions method on the qpid::messaging::Connection
class, which resets any sessions that are in error. I also added a
resetSession on the qpid::messaging::Session class. I was unsure whether
to add a resetSession method that took a Session name parameter. In the
end I decided against it.
Interestingly as part of this work I looked at the
ConnectionImpl::newSession implementation
(src/qpid/client/amqp0_10/ConnectionImpl.cpp). I saw that the current
implementation of this method just overwrites an existing session with
the same name. Not sure that this is quite right as this would infer
that any Senders/Receivers associated with the previous Session would
get closed and not associated with the newly created named session. I
would of expected the newSession implementation to throw an exception if
a Session with the same name already existed, but perhaps I am just
missing something.
I will also be adding another posting about several issues I have
discovered with the qpid::messaging::Sender implementation. I am just
writing the boost unit tests so that I can attach the code that
exercises the issues. In summary they are
- TTL on a message does not get adjusted when stored in the outgoing
Sender queue and the queue cannot be emptied due to broker unavailability.
- getUnsettled segmentation error when called with no connection to
broker but messages in the Sender outgoing queue (fine with zero size
outbound queue).
- Session::checkError, can throw NotAttachedException which ultimately
extends from qpid::Exception, but I cannot find qpid::Exception in the
installation directory. I have qpid::types::Exception and
qpid::messaging::Exception.
- Inconsistent behavior of Sender when Broker not connected. When
sending a message an Exception occurs, as no connection, but messages
are still placed in outbound queue up until the Sender is flushed
('window < Capacity/4' , not sure where the 4 comes from). At this point
any further sent messages still cause an exception, but messages do not
get placed in the outbound queue. Varying the capacity varies when this
occurs and so doesn't seem correct.
Happy to try and submit, not something I have done before with QPID.
What is the best way to go about it?
Clive.
On 09/06/2014 09:44, Gordon Sim wrote:
On 06/08/2014 02:54 PM, CLIVE wrote:
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.
The reason you want to reset the session, rather than just creating a
new one, is that it is referenced elsewhere?
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?
No, I can't think of any reason not to allow something like that. If
you want to submit a patch, I'll be happy to help you get it committed.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
