FWIW - I've opened a JIRA for this: https://issues.apache.org/jira/browse/PROTON-656
----- Original Message ----- > From: "Gordon Sim" <[email protected]> > To: [email protected] > Sent: Wednesday, September 3, 2014 10:52:03 AM > Subject: Re: Q: change in transport behavior since 0.7 > > > ----- Original Message ----- > >> From: "Ken Giusti" <[email protected]> > >> To: [email protected] > >> Cc: [email protected] > >> 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: [email protected] > For additional commands, e-mail: [email protected] > > -- -K --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
