You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Gordon Sim <gs...@redhat.com> on 2014/09/03 16:52:03 UTC
Re: Q: change in transport behavior since 0.7
> ----- Original Message -----
>> From: "Ken Giusti" <kg...@redhat.com>
>> To: proton@qpid.apache.org
>> Cc: users@qpid.apache.org
>> Sent: Wednesday, August 27, 2014 3:15:23 PM
>> Subject: Q: change in transport behavior since 0.7
>>
>> Hi,
>>
>> I've started hitting some pygnus negative test failures on trunk that used to
>> pass on 0.7. There seems to have been an change to the behavior in the
>> pn_transport_close_head() and pn_transport_close_tail() api as part of this
>> checkin:
>>
>> http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/src/transport/transport.c?r1=1611460&r2=1611461
>>
>> On 0.7, these methods used to return error codes should the close occur at an
>> unexpected point in the protocol exchange. Specifically, my tests that are
>> failing try to simulate a premature socket close by calling
>> pn_transport_close_{head,tail}() immediately after the connection state has
>> hit LOCAL_ACTIVE|REMOTE_ACTIVE.
>>
>> Pyngus had used the error codes to signal the 'connection_failure()' callback
>> to the application. The tests that verify that the callback gets triggered
>> on a premature socket close are now failing.
>>
>> Pyngus' 'lower-half' is pretty stupid, and merely shuttles bytes between the
>> sockets and the transports. Should a socket close, the lower-half really
>> isn't aware of the state of the connection (clean close, or aborted).
>>
>> Is there a better method for detecting connection aborts?
I'm interested in the answer to this also. In the proton python examples
I've been working on, I wanted to handle disconnection. I tested the
state on the proton connection to determine if it was clean/not-clean.
If there is a better way I'd switch to that.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Q: change in transport behavior since 0.7
Posted by Ken Giusti <kg...@redhat.com>.
FWIW - I've opened a JIRA for this:
https://issues.apache.org/jira/browse/PROTON-656
----- Original Message -----
> From: "Gordon Sim" <gs...@redhat.com>
> To: users@qpid.apache.org
> Sent: Wednesday, September 3, 2014 10:52:03 AM
> Subject: Re: Q: change in transport behavior since 0.7
>
> > ----- Original Message -----
> >> From: "Ken Giusti" <kg...@redhat.com>
> >> To: proton@qpid.apache.org
> >> Cc: users@qpid.apache.org
> >> Sent: Wednesday, August 27, 2014 3:15:23 PM
> >> Subject: Q: change in transport behavior since 0.7
> >>
> >> Hi,
> >>
> >> I've started hitting some pygnus negative test failures on trunk that used
> >> to
> >> pass on 0.7. There seems to have been an change to the behavior in the
> >> pn_transport_close_head() and pn_transport_close_tail() api as part of
> >> this
> >> checkin:
> >>
> >> http://svn.apache.org/viewvc/qpid/proton/trunk/proton-c/src/transport/transport.c?r1=1611460&r2=1611461
> >>
> >> On 0.7, these methods used to return error codes should the close occur at
> >> an
> >> unexpected point in the protocol exchange. Specifically, my tests that
> >> are
> >> failing try to simulate a premature socket close by calling
> >> pn_transport_close_{head,tail}() immediately after the connection state
> >> has
> >> hit LOCAL_ACTIVE|REMOTE_ACTIVE.
> >>
> >> Pyngus had used the error codes to signal the 'connection_failure()'
> >> callback
> >> to the application. The tests that verify that the callback gets
> >> triggered
> >> on a premature socket close are now failing.
> >>
> >> Pyngus' 'lower-half' is pretty stupid, and merely shuttles bytes between
> >> the
> >> sockets and the transports. Should a socket close, the lower-half really
> >> isn't aware of the state of the connection (clean close, or aborted).
> >>
> >> Is there a better method for detecting connection aborts?
>
> I'm interested in the answer to this also. In the proton python examples
> I've been working on, I wanted to handle disconnection. I tested the
> state on the proton connection to determine if it was clean/not-clean.
> If there is a better way I'd switch to that.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org