----- 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]
