qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Q: change in transport behavior since 0.7
Date Wed, 03 Sep 2014 14:52:03 GMT
> ----- Original Message -----
>> From: "Ken Giusti" <kgiusti@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
>> 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

View raw message