You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Ken Giusti <kg...@redhat.com> on 2014/08/27 21:15:23 UTC
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: 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
Re: Q: change in transport behavior since 0.7
Posted by Gordon Sim <gs...@redhat.com>.
> ----- 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>.
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" <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?
>
> thanks,
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org
Re: Q: change in transport behavior since 0.7
Posted by Ken Giusti <kg...@redhat.com>.
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" <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?
>
> thanks,
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
--
-K
Re: Q: change in transport behavior since 0.7
Posted by Ken Giusti <kg...@redhat.com>.
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" <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?
>
> thanks,
>
> -K
>
> ---------------------------------------------------------------------
> 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