Just to follow up some off-list musings, Wouldn't it make sense to have the event system dispatch this type of failure as an *_ERROR event?
I think an error event would make sense, at least for the Transport and Connection event categories, when an unrecoverable protocol-level error is encountered. Having such an error code means the underlying socket driver can be as dumb as possible: merely moving data between the transport and the socket, and closing the stream in response to a socket close. The error would be handled by the event processing "top half" - which is probably the more natural place to handle a failing connection or transport object. Thoughts? ----- 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? > > thanks, > > -K > > --------------------------------------------------------------------- > 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]
