[
https://issues.apache.org/jira/browse/PROTON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16996608#comment-16996608
]
Charles E. Rolke commented on PROTON-2162:
------------------------------------------
i re-ran the dispatch tests with 0.29 and there are just as many framing-error
closes as with 0.30. So that's not a regression and I was mistaken to call it
so.
I understand what what [~robbie] is saying, I'm pretty sure.
I'm really surprised that a framing-error is an acceptable reason to declare in
a close condition in any case *but* when the tcp connection is still valid.
* If tcp is valid and there's a framing error then that's the condition that
should close the connection and that should be the condition in the close frame.
* If tcp is invalid then who cares about the framing error? The framing error
is not what triggered the connection close but it is an obvious and secondary
side effect of the tcp connection closing. The main issue is that the tcp
connection disappeared. In this case the tcp connection closing is the
condition that the AMQP close should declare and not the framing error.
Taking a customer, client-side view here. The proton client library has two
interfaces: one with the invoking client and the other with the remote peer on
the wire. In the base issue case the invoking client has attached, received one
aborted message, and then exited the process. From that customer's point of
view there was never a framing error. The proton library, of course, has a
communication with the remote peer which, upon connection disconnect, has both
a tcp disconnect and a possible subsequent AMQP framing error. At the moment
that the customer exited his process only the cpp proton library cares about
the framing error and not the customer client. How is it that the close should
be a framing error and not a proton:io connection close?
When I run the qpid-dispatch self tests the closes are polluted with over 1,000
framing-error conditions. In fact there are no framing errors at all but rather
a bunch of closed connections on top of messages in progress. Maybe this is
material for another jira.
> [c] Regression with aborted transfers: connection closes with framing error
> ---------------------------------------------------------------------------
>
> Key: PROTON-2162
> URL: https://issues.apache.org/jira/browse/PROTON-2162
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
> Affects Versions: proton-c-0.29.0
> Environment: Fedora 29, debug build
> Reporter: Charles E. Rolke
> Priority: Major
>
> Using normal example code:
> * run build/cpp/examples/direct_recv
> * run build/c/examples/send-abort
> Tested against 0.27.1, 0.28.0, 0.29.0, and 0.30.1-rc1
> In all cases direct_recv exits with a 'receiver read failure' upon receiving
> the first aborted transfer.
> In older versions (before 0.30.x) send_abort receives a close with error:
> {noformat}
> 0 -> @close(24) [error=@error(29) [condition=:"proton:io",
> description="Connection reset by peer - on write to :5672 (connection
> aborted)"]]
> {noformat}
> In the 0.30.1-rc1 version the send_abort receives a close with error:
> {noformat}
> AMQP:FRAME:0 -> @close(24) [error=@error(29)
> [condition=:"amqp:connection:framing-error", description="connection
> aborted"]]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
