[
https://issues.apache.org/jira/browse/PROTON-2162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16997204#comment-16997204
]
Robbie Gemmell edited comment on PROTON-2162 at 12/16/19 11:52 AM:
-------------------------------------------------------------------
I agree that use of framing-error is odd and potentially confusing in many
cases it might currently get used (since its used as a kind of catch-all). To
be clear, my only argument in the earlier comment was that after testing this
it didn't really seem to be a newly introduced behaviour at all so much as a
(in your case) more likely timing variation and therefore not really any
regression, and especially not a reason to scrub the 0.30.0 release >72hrs into
the RC1 vote.
On the variability, could it be that multiple conditions are being set on the
transport and perhaps there is either ordering variation, or just variability
on whether >1 attempt to set a condition occurs (depending on how many bytes
in/out are outstanding at the time etc), with the last one 'winning'? I made a
change (/redid a PR) some time ago to ensure that when the proton-j transport
had multiple error conditions set on it or was closed prematurely (and thus set
an error condition on itself), the first effective error condition was always
the one retained for later use and inspection. Perhaps a similar change would
help avoid such variability here if it exists.
I'd also be quite fine with changing it to use some other fallback error
condition. I recently changed proton-j to ensure it used amqp:decode-error for
internally prompted transport closures that had originated from a decode error
occurring for example.
I would suggest a new Jira for such changes though, and other issues Andrew
noted. They can link to this one, but theres likely too much unrelated and
cross concern discussion here to use it for much at this point.
was (Author: gemmellr):
I agree that use of framing-error is odd and potentially confusing in many
cases it might currently get used (since its used as a kind of catch-all). To
be clear, my only argument in the earlier comment was that after testing this
it didn't really seem to be a newly introduced behaviour at all so much as a
(in your case) more likely timing variation and therefore not really any
regression, and especially not a reason to scrub the 0.30.0 release >72hrs into
the RC1 vote.
On the variability, could it be that multiple conditions are being set on the
transport and perhaps there is either ordering variation, or just variability
on whether >1 attempt to set a condition occurs (depending on how many bytes
in/out are outstanding at the time etc), with the last one 'winning'? I made a
change (/redid a PR) some time ago to ensure that when the proton-j transport
had multiple error conditions set on it or was closed prematurely (and thus set
an error condition on itself), the first effective error condition was always
the one retained for later use and inspection. Perhaps a similar change would
help avoid such variability here if it exists.
I'd also be quite fine with changing it to use some other fallback error
condition. I recently changed proton-j to ensure it used amqp:decode-error for
internally prompted transport closures that had originated from a decode error
occurring for example.
> [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]
