You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2015/03/12 17:35:38 UTC

[jira] [Closed] (QPID-6094) [0-8..0-9-1] Java Broker can interleave other frames (for the same channel) amongst content frames

     [ https://issues.apache.org/jira/browse/QPID-6094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Keith Wall closed QPID-6094.
----------------------------
    Resolution: Fixed

> [0-8..0-9-1] Java Broker can interleave other frames (for the same channel) amongst content frames
> --------------------------------------------------------------------------------------------------
>
>                 Key: QPID-6094
>                 URL: https://issues.apache.org/jira/browse/QPID-6094
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: 0.18, 0.22, 0.30, 0.32
>            Reporter: Keith Wall
>             Fix For: 6.0 [Java]
>
>
> A longstanding defect in the Java Broker means that it can interleave other frames for same channel amongst content frames belonging to a single message.  This violates the AMQP specification.  It is most likely to be seen when the messages sizes are large and/or frame sizes small.
> AMQ Spec 0-9-1; 4.2.6 Content Framing
> bq. "Content frames on a specific channel are strictly sequential. That is, they may be mixed with frames for other channels, but no two content frames from the same channel may be mixed or overlapped, nor may content frames for a single content be mixed with method frames on the same channel"
> Here is an example from the Java Broker log (trunk).  Here a CommitOk is sent interleaved between two body frames belonging of the same message.  
> {noformat}
> 2014-09-12 13:00:56,577 DEBUG [pool-1-thread-1] (v0_8.AMQProtocolEngine) - SEND: [CompositeAMQBodyBlock methodBody=[EncodedDeliveryBody underlyingBody: [BasicDeliverBodyImpl: consumerTag=sgen_1, deliveryTag=24, redelivered=false, exchange=null, routingKey=q]], headerBody=ContentHeaderBody{classId=60, weight=0, bodySize=65535, properties=reply-to = null,propertyFlags = 0,ApplicationID = null,ClusterID = null,UserId = null,JMSMessageID = null,JMSCorrelationID = null,JMSDeliveryMode = 0,JMSExpiration = 0,JMSPriority = 0,JMSTimestamp = 0,JMSType = null}, contentBody=[MessageContentSourceBody offset: 0, length: 65527], channel=1]
> 2014-09-12 13:00:56,577 DEBUG [IoReceiver - /127.0.0.1:49936] (txn.LocalTransaction) - Completed post transaction actions
> 2014-09-12 13:00:56,583 DEBUG [IoReceiver - /127.0.0.1:49936] (v0_8.AMQProtocolEngine) - SEND: Frame channelId: 1, bodyFrame: [TxCommitOkBodyImpl: ]
> 2014-09-12 13:00:56,583 DEBUG [IoReceiver - /127.0.0.1:49936] (v0_8.AMQProtocolEngine) - Frame handled in 7 ms. Frame: Frame channelId: 1, bodyFrame: [TxCommitBodyImpl: ]
> 2014-09-12 13:00:56,583 DEBUG [IoReceiver - /127.0.0.1:49936] (v0_8.AMQChannel) - sync() called on channel 1(213308972)
> 2014-09-12 13:00:56,583 DEBUG [pool-1-thread-1] (v0_8.AMQProtocolEngine) - SEND: Frame channelId: 1, bodyFrame: [MessageContentSourceBody offset: 65527, length: 8]
> {noformat}
> The Java Client tolerates this behaviour (longstanding).  QPID-6082 made the Python Client 0-8..0-9-1 do the same.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org