qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6651) Proton recv issue connecting to QPID Java Broker
Date Thu, 23 Jul 2015 16:00:07 GMT

    [ https://issues.apache.org/jira/browse/QPID-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14639049#comment-14639049

Robbie Gemmell commented on QPID-6651:

I had a quick play with this. I was able to make C Messenger send+recv examples do what was
described against the Java broker (though I had to use slightly different size of messages),
but not the C++ broker. I expected that when I started, both due to what was reported here,
and some stuff I have been looking at this week which would likely explain the difference

Proton defaults to setting the max frame size value to its largest value (either by specifying
that directly, or not specifying a value and getting the default). The C++ broker doesnt seem
to set a specific limit itself so it gets that default behaviour, which means that proton-based
clients which do the same will not actually split messages into multiple frames when sending
to the C++ broker. Similarly, that means C++ broker wont split outgoing messages into multiple
frames for proton-based clients that havent secified a particular frame size limit.

The Java broker on the other hand is setting the max frame size in its Open frame to 32768,
and so proton-based clients will fragment messages sent to the Java broker if they would exceed
that. The broker also similarly fragments messages it is sending to proton-based clients though
the client doesnt strictly require it.

I agree with Robs observation that this could point to an issue with proton-c. I tried to
prove that by hacking proton-j (since I dont know where to do the same in proton-c) such that
the new JMS client using it would fragment messages being sent to the C++ broker despite the
brokers advertised max frame size not actually requiring it. I expected that to fail but it
didnt, the broker received the multiple frames for the message and sent it back out (in 1
frame) without issue, to both the JMS client and the C Messenger recv example.

I'm away for the next few days but I'll post on the proton list to point out this seems like
an proton-c issue (beign honest im about at the limit of my proton-c debugging capability
here anyway hehe).


> 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://  `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://
> {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

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

View raw message