In the process of producing the patch for the reset Session
functionality and producing some boost test cases to demonstrate the
other issues I have discovered. Hope to raise a JIRA(s) in the next few
days once I have pulled everything together.
On 09/06/2014 20:38, Gordon Sim wrote:
On 06/09/2014 08:05 PM, CLIVE wrote:
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.
I think a reset() method on the Session would be the clearest. I don't
object to having the resetSessions() on a Connection as well.
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 agree with you, the current behaviour sounds wrong. Must just have
been an oversight.
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.
Very helpful summary! It would be great to get a JIRA[1] for all of
those, thanks for reporting these!
Happy to try and submit, not something I have done before with QPID.
What is the best way to go about it?
Create a JIRA[1] and attach a patch to that.
[1] https://issues.apache.org/jira/browse/QPID
---------------------------------------------------------------------
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]
