[
https://issues.apache.org/jira/browse/PROTON-2173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097647#comment-17097647
]
Justin Ross commented on PROTON-2173:
-------------------------------------
Proton is behaving as intended here. If the remote peer closes one half of the
TCP connection without a clean AMQP close, Proton correctly notifies the peer
by sending an AMQP close with an error condition. Since the other half of the
TCP connection can remain open, the peer can receive the information. And in
general, programs that don't close cleanly should be made aware of it.
Proton's use of a framing error here is incorrect. The AMQP spec language
excludes its use for this, and the spec doesn't have a other good built-in
options, so we should use a custom error that is sufficiently descriptive. I
raised PROTON-2173 for this part.
> [c, cpp] Idle connections closed with TCP FIN cause framing errors
> ------------------------------------------------------------------
>
> Key: PROTON-2173
> URL: https://issues.apache.org/jira/browse/PROTON-2173
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.30.0
> Reporter: Charles E. Rolke
> Priority: Major
>
> This issue was mis-characterized in PROTON-2162 but the same basic problem
> stands. When a completely idle connection is closed with an incoming TCP FIN
> then the connection emits a close frame with a framing error. This is a
> normal, clean connection close and there is no framing error.
> Demonstrate this using cpp examples direct_recv and simple_send.
> * modify simple_send on_sendable() so that it just returns without sending
> anything
> * run direct_recv
> * run simple_send
> * let it sit. There is no traffic.
> * kill simple_end by pid with dash 9
> * simple_send prints "killed"
> * direct_recv prints "amqp:connection:framing-error: connection aborted"
> Wireshark shows three frames over the wire:
> * --> 5672 FIN
> * <-- 5672 CLOSE amqp:connection:framing-error:connection aborted
> * --> 5672 RST
> This is an abnormal connection closure. One end has sent a FIN and then later
> the other end sends a message to it. The OS should never have to reply to
> that message with a RST.
> AmqpNetLite gets it right. Run examples PeerToPeer.Server and .Client with
> client modified never to send anything but just open the connection and sit
> there. Then kill the client. Over the wire:
> * --> 5672 FIN
> * <-- 5672 FIN ACK
> * --> 5672 ACK
> This is a normal connection closure TCP handshake. The server prints:
> Exception: The transport 'ListenerTcpTransport' is closed.
> Dispatch customers are asking why there are so many framing errors even when
> running common utilities like qdstat. And there are so many framing errors
> reported that if a real framing error ever shows up it will never be seen.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
