You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by CLIVE <cl...@ckjltd.co.uk> on 2014/06/08 15:54:00 UTC
messaging API Connection open but Session in error
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by Gordon Sim <gs...@redhat.com>.
On 06/09/2014 08:05 PM, CLIVE wrote:
> - 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.
I've checked in a fix for this. The behaviour now is that if
disconnected and a flush() or sync() (which are used to free up
capacity) fails, the send will ignore that and try to continue with the
send anyway providing there is capacity. This means of course that the
send will still fail with a TransportFailure, but the message will
always be added to the replay buffer if there is any remaining capacity.
If there is no capacity remaining (and we can't free any using sync() or
flush() due to being disconnected), the behaviour depends on whether
auto-reconnect is in use on the connection.
If it is, the TransportFailure will be thrown as before, meaning the
auto-reconnect will kick in and essentially block the call until we can
connect and sync(), freeing capacity for the send.
If auto-reconnect is not in use, then an OutOfCapacity is thrown rather
than the TransportFailure. This allows the application handling the
exception to differentiate between the case where the message does need
to be explicitly resent and the case where it has already been queued
for replay on reconnection.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by CLIVE <cl...@ckjltd.co.uk>.
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by CLIVE <cl...@ckjltd.co.uk>.
Gordon,
Created JIRA QPID-5824, to capture the addition of a reset() method to
the qpid::messaging::Session class.
I've not used JIRA before so you might what to check that I have got the
details correct.
Working on a patch today, hope to attach the code later this afternoon.
Clive
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
> .
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by CLIVE <cl...@ckjltd.co.uk>.
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: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: messaging API Connection open but Session in error
Posted by Gordon Sim <gs...@redhat.com>.
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org