[
https://issues.apache.org/jira/browse/QPID-6784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14958833#comment-14958833
]
Keith Wall commented on QPID-6784:
----------------------------------
I think {{NBC._unexpectedByteBufferSizeUsed}} needs to be volatile to avoid a
publication issue. NonBlockingConnections are run by any thread in the IO
pools. Also the name does not convey the purpose - should it not be
_unexpectedByteBufferSizeReported?
> [Java Broker, Java Client] Client sends too large frames and broker does
> wrong frame size validation on 0-9
> -----------------------------------------------------------------------------------------------------------
>
> Key: QPID-6784
> URL: https://issues.apache.org/jira/browse/QPID-6784
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Client
> Affects Versions: 0.17, 0.32
> Reporter: Lorenz Quack
> Assignee: Keith Wall
> Priority: Blocker
> Fix For: qpid-java-6.0
>
>
> The Client does not include the frame attributes (except for 1 byte) in its
> calculation of the AMQP Frame size thus creating frames which are 7 bytes too
> large. This happens in
> {{org.apache.qpid.client.BasicMessageProducer_0_8#calculateContentBodyFrameCount}}
> and maybe other places.
> The broker on the other end does an incorrect validation (in
> {{AMQDecoder#decodable}} at least) where it does not take any of the
> attributes into account thus accepting too large frames.
> Besides not being compliant with the spec this causes problems in
> {{NonBlockingConnectionPlainDelegate#processData}} where the frame does not
> fit into a single networkBuffer.
> I did not investigate other protocol versions.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
