[
https://issues.apache.org/jira/browse/QPID-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14637684#comment-14637684
]
Rob Godfrey commented on QPID-6651:
-----------------------------------
So looking at the log that you sent, my suspicion is that the error is on the
Proton side rather than the Java Broker side... and that the difference between
the Java and C++ Brokers is probably how they are breaking up large messages
into separate frames.
Just extracting the log lines for the connection on port 54180 (which is the
one which fails with the invalid field error), and looking only at Frame level
logging (which excludes the payload), we can see this is the totality of the
interaction:
{noformat}
SEND[/10.211.55.14:54180|0] : SaslMechanisms{saslServerMechanisms=[ANONYMOUS]}
RECV[/10.211.55.14:54180|0] : SaslInit{mechanism=ANONYMOUS,initialResponse=}
SEND[/10.211.55.14:54180|0] : SaslOutcome{code=ok}
RECV[/10.211.55.14:54180|0] :
Open{containerId=c64450fb-a0b8-4c3c-b7f8-4e94c6fe4b69,hostname=10.211.55.14}
SEND[/10.211.55.14:54180|0] :
Open{containerId=a6764332-496f-44f8-8fde-2fcce91dd3f1,maxFrameSize=32768,channelMax=255,properties={product=qpid,
version=0.32, qpid.build=Unversioned directory, qpid.instance_name=Broker}}
RECV[/10.211.55.14:54180|0] :
Begin{nextOutgoingId=0,incomingWindow=2147483647,outgoingWindow=0}
SEND[/10.211.55.14:54180|0] :
Begin{remoteChannel=0,nextOutgoingId=0,incomingWindow=2048,outgoingWindow=2048}
RECV[/10.211.55.14:54180|0] :
Attach{name=MAMA/PHIL,handle=0,role=receiver,sndSettleMode=mixed,rcvSettleMode=first,source=Source{address=MAMA/PHIL,durable=none,timeout=0,dynamic=false},target=Target{address=MAMA/PHIL,durable=none,timeout=0,dynamic=false},initialDeliveryCount=0}
SEND[/10.211.55.14:54180|0] :
Attach{name=MAMA/PHIL,handle=0,role=sender,sndSettleMode=mixed,rcvSettleMode=first,source=Source{address=MAMA/PHIL,durable=none,timeout=0,dynamic=false,distributionMode=copy},target=Target{address=MAMA/PHIL,durable=none,timeout=0,dynamic=false},initialDeliveryCount=0}
RECV[/10.211.55.14:54180|0] :
Flow{incomingWindow=2147483647,nextOutgoingId=0,outgoingWindow=0,handle=0,deliveryCount=0,linkCredit=1024,drain=false}
SEND[/10.211.55.14:54180|0] :
Transfer{handle=0,deliveryId=0,deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x00,messageFormat=0}
RECV[/10.211.55.14:54180|0] :
Disposition{role=receiver,first=0,last=0,settled=true}
SEND[/10.211.55.14:54180|0] :
Transfer{handle=0,deliveryId=1,deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x01,messageFormat=0,more=true}
SEND[/10.211.55.14:54180|0] :
Transfer{handle=0,deliveryId=1,deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x01,messageFormat=0}
RECV[/10.211.55.14:54180|0] :
Disposition{role=receiver,first=1,last=1,settled=true}
RECV[/10.211.55.14:54180|0] :
Close{error=Error{condition=amqp:session:invalid-field,description=sequencing
error, expected delivery-id 2, got 1}}
SEND[/10.211.55.14:54180|0] : Detach{handle=0,closed=true}
SEND[/10.211.55.14:54180|0] : Close{}
{noformat}
In particular what this shows is that the broker is sending two transfer
frames, the first with more=true (indicating that a further frame for the same
delivery will be arriving), then second does not set the more flag (so it is
implicitly false). If this is how the frames are actually sent on the wire
(would be good to check the proton logs here) then the client should not be
expecting delivery id 2 rather than delivery id 1 for the second transfer frame
for deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x01
> Proton recv issue connecting to QPID Java Broker
> ------------------------------------------------
>
> Key: QPID-6651
> URL: https://issues.apache.org/jira/browse/QPID-6651
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Java Broker
> Affects Versions: 0.32
> Environment: Mac OS X 10.10.4, Java 1.8.0_45
> Centos 7, Java 1.8.0_45 (VM)
> Reporter: Philip Preston
> Attachments: qpid.log
>
>
> I have been testing the broker based functionality that is being added to
> OpenMAMA (www.openmama.org) through use of the proton-c (0.8) and have come
> across an issue I have been able to reproduce with the {{send}} / {{recv}}
> proton example applications.
> The issue is the the {{recv}} application is not able to receive large
> messages from the send application through the Java QPID Broker, but sending
> the same message through the C++ QPID Broker it works fine.
> This is reproducible as follows:
> * Java QPID Broker is setup relatively vanilla - simply switching the
> authentication to Anonymous, and adding a new topic exchange called "MAMA"
> (setup on Linux or Mac OS X)
> * C++ QPID Broker is built with AMQP_1 support and ran with
> {{--topic-patterns MAMA.*}} (setup on Linux)
> I run the {{send}} application as follows:
> {noformat}
> ./send -a topic://10.211.55.14/MAMA/PHIL `for i in {1..32640}; do echo -n
> "x" ; done`
> {noformat}
> This is just generating a large message to send. On the receive side it is
> ran as follows:
> {noformat}
> ./recv topic://10.211.55.14/MAMA/PHIL
> {noformat}
> In the case when the number of characters sent is 32640 the message works
> fine. If I increase the characters to 32641 (or more) then the {{recv}}
> application has issues. The issue is different on Mac vs Linux so:
> *Mac*
> {noformat}
> Assertion failed: (msg && bytes && size), function pn_message_decode, file
> /Users/ppreston/Developer/Libraries/Source/qpid-proton/proton-c/src/message/message.c,
> line 656.
> Abort trap: 6
> {noformat}
> *Linux*
> {noformat}
> [0x10a3ab0]:ERROR amqp:session:invalid-field sequencing error, expected
> delivery-id 2, got 1
> {noformat}
> If I run the exact same test to the C++ QPID Broker (0.32) there is no issue
> at all. Certainly with the Linux error message something is getting out of
> sync with large messages, which are fragmented?
> I have attached the Java Broker Log (ran on Linux) for a run of the above
> where a Mac {{recv}} and Linux {{recv}} are running, and a message is send
> from Linux {{send}}.
> Let me know if any extra information required.
> Thanks
> Phil
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
