[
https://issues.apache.org/jira/browse/PROTON-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Stitcher updated PROTON-2098:
------------------------------------
Description:
This can be demonstrated by using the python examples simple_sender.py and
direct_recv.py. If you turn logging on for direct_recv.py you will see:
{code}
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_readable(<proton._selectable.Selectable
object at 0x7f99e049a850>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event:
PN_TRANSPORT_TAIL_CLOSED(<proton._transport.Transport 0x7f99e049aed0 ~
0x55910988bfe0>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT_CLOSED(<proton._transport.Transport
0x7f99e0cf09d0 ~ 0x55910988bfe0>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT_ERROR(<proton._transport.Transport
0x7f99e049af50 ~ 0x55910988bfe0>)
20190830-11:22:09:proton:ERROR: amqp:connection:framing-error: connection
aborted
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_final(<proton._selectable.Selectable
object at 0x7f99e049a850>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event:
PN_CONNECTION_UNBOUND(<proton._endpoints.Connection 0x7f99e049afd0 ~
0x55910988beb0>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT(<proton._transport.Transport
0x7f99e0cf09d0 ~ 0x55910988bfe0>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_final(<proton._reactor.TimerSelectable
object at 0x7f99e049a6d0>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> Stopping
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: reactor_final(<proton._reactor.Container object at
0x7f99e0478d50>)
20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> Stopping
{code}
Note the ERROR a few lines from the end.
This makes the server end see a transport-error (as the socket was abruptly
disconnected) which seems like an error. Although a well written server should
not really care about this anyway as it has already shut down the connection
from its pov.
Arguably there should be no transport-error in this circumstance at the server
end. But it would definitely be better behaved if the client correctly closed
the connection from its end.
was:
This can be demonstrated by using the python examples simple_sender.py and
direct_recv.py. If you turn logging on for direct_recv.py you will see:
{quote}{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_readable(<proton._selectable.Selectable
object at 0x7f99e049a850>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event:
PN_TRANSPORT_TAIL_CLOSED(<proton._transport.Transport 0x7f99e049aed0 ~
0x55910988bfe0>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT_CLOSED(<proton._transport.Transport
0x7f99e0cf09d0 ~ 0x55910988bfe0>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT_ERROR(<proton._transport.Transport
0x7f99e049af50 ~ 0x55910988bfe0>)}}
{{20190830-11:22:09:proton:ERROR: amqp:connection:framing-error: connection
aborted}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_final(<proton._selectable.Selectable
object at 0x7f99e049a850>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event:
PN_CONNECTION_UNBOUND(<proton._endpoints.Connection 0x7f99e049afd0 ~
0x55910988beb0>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: PN_TRANSPORT(<proton._transport.Transport
0x7f99e0cf09d0 ~ 0x55910988bfe0>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: selectable_final(<proton._reactor.TimerSelectable
object at 0x7f99e049a6d0>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> Stopping}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> recvd Event: reactor_final(<proton._reactor.Container object at
0x7f99e0478d50>)}}
{{20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
0x7f99e0478d50> Stopping}}
{quote}
Note the ERROR a few lines from the end.
This makes the server end see a transport-error (as the socket was abruptly
disconnected) which seems like an error. Although a well written server should
not really care about this anyway as it has already shut down the connection
from its pov.
Arguably there should be no transport-error in this circumstance at the server
end. But it would definitely be better behaved if the client correctly closed
the connection from its end.
> [Python] client abruptly disconnects after receiving disconnect-close-half
> socket close sequence
> ------------------------------------------------------------------------------------------------
>
> Key: PROTON-2098
> URL: https://issues.apache.org/jira/browse/PROTON-2098
> Project: Qpid Proton
> Issue Type: Bug
> Components: python-binding
> Affects Versions: proton-c-0.28.0
> Reporter: Andrew Stitcher
> Assignee: Andrew Stitcher
> Priority: Major
>
> This can be demonstrated by using the python examples simple_sender.py and
> direct_recv.py. If you turn logging on for direct_recv.py you will see:
> {code}
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event:
> selectable_readable(<proton._selectable.Selectable object at 0x7f99e049a850>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event:
> PN_TRANSPORT_TAIL_CLOSED(<proton._transport.Transport 0x7f99e049aed0 ~
> 0x55910988bfe0>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event: PN_TRANSPORT_CLOSED(<proton._transport.Transport
> 0x7f99e0cf09d0 ~ 0x55910988bfe0>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event: PN_TRANSPORT_ERROR(<proton._transport.Transport
> 0x7f99e049af50 ~ 0x55910988bfe0>)
> 20190830-11:22:09:proton:ERROR: amqp:connection:framing-error: connection
> aborted
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event: selectable_final(<proton._selectable.Selectable
> object at 0x7f99e049a850>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event:
> PN_CONNECTION_UNBOUND(<proton._endpoints.Connection 0x7f99e049afd0 ~
> 0x55910988beb0>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event: PN_TRANSPORT(<proton._transport.Transport
> 0x7f99e0cf09d0 ~ 0x55910988bfe0>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event:
> selectable_final(<proton._reactor.TimerSelectable object at 0x7f99e049a6d0>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> Stopping
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> recvd Event: reactor_final(<proton._reactor.Container object
> at 0x7f99e0478d50>)
> 20190830-11:22:09:proton:DEBUG: <proton._reactor.Container object at
> 0x7f99e0478d50> Stopping
> {code}
> Note the ERROR a few lines from the end.
> This makes the server end see a transport-error (as the socket was abruptly
> disconnected) which seems like an error. Although a well written server
> should not really care about this anyway as it has already shut down the
> connection from its pov.
> Arguably there should be no transport-error in this circumstance at the
> server end. But it would definitely be better behaved if the client correctly
> closed the connection from its end.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
