[
https://issues.apache.org/jira/browse/QPID-8523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363503#comment-17363503
]
Robbie Gemmell commented on QPID-8523:
--------------------------------------
The changes resolve the initially observed issue, though functionally things
remain about the same as before, since this just lets things proceed long
enough for it to be seen the broker actually kills the session itself.
With the client no longer fouling on the invalid attach encoding and killing
the connection on its own, some subsequent activity was then revealed. The
client pipelined a flow of credit with the receiver attach, and the broker then
tears down the session itself after the link refusal to non-existing address
with an errant link error. Its perhaps slightly debatable that this is what the
spec says to do since it discusses it separate to link refusal. The general
behaviour it is what all the proton-c based clients clients have done for a
decade though and I probably don't see that changing given how they work (and
now the ProtonJ2 imperative client does the same and was used to discover this
issue, it could perhaps change more easily). Functionality, I think it might be
nicer for the broker to ignore a flow in this case given its the brokers
decision to send anything which it clearly wont and clients will know that when
they eventually receive the attach+detach and send their own detach, so tearing
down the session in this case mostly just seems to make things more awkward.
> [Broker-J] refusing-attach while rejecting consumer does not set required
> initial-delivery-count field
> ------------------------------------------------------------------------------------------------------
>
> Key: QPID-8523
> URL: https://issues.apache.org/jira/browse/QPID-8523
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Affects Versions: qpid-java-broker-8.0.4
> Reporter: Robbie Gemmell
> Priority: Major
>
> Attempting to create a consumer link from e.g. a non-existing address results
> in refusal of the link, which in case of a consumer is done by sending a
> 'response' attach with null source to indicate the terminus wasnt created,
> followed by a detach with the error.
> The broker does send an attach without a source, but it omits the
> initialDeliveryCount value from the attach, which the spec says is required
> when role=SENDER ("This MUST NOT be null if role is sender, and it is ignored
> if the role is receiver."). Protocol libraries validating such required
> values will run afoul of this, leading to decode error that can bring the
> connection down unnecessarily.
> From looking at the wire encoding, it appears only the first 3 fields (name,
> handle, role) of the attach are being set, with the rest unpopulated and thus
> being equivalent to null or any default they may have.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
