Hi Phil, this seems odd - I know people have been sending and receiving to/from the Java Broker successfully using Proton. Can you turn on debug logging in the Java Broker (edit your log4j.xml config file and move all the thresholds down to DEBUG for instance)? If you can create a JIRA for this issue (https://issues.apache.org/jira/browse/QPID) and attach any DEBUG log as attachments that would be really helpful.
Out of interest - have you tried with newer versions of Proton? -- Rob On 22 July 2015 at 00:44, Philip Preston <[email protected]> wrote: > Hey > > I was testing the broker implementation that is currently being worked on > in OpenMAMA and came across an issue, which I have been able to recreate > with proton send / recv example apps. > > The issue is seen with sending large payloads to Java QPID Broker using > the proton send application as follows: > > ./send -a topic://127.0.0.1/MAMA/PHIL <string from file - in this case > 47104 bytes> > > And the receive as per below: > > ./recv topic://127.0.0.1/MAMA/PHIL > > I am running the Java QPID Broker v0.32 running with java v1.8.0_45 - > vanilla setup (although I have ran this java broker on Centos 7 along with > the clients to be sure not a mac thing). The message makes it to the recv > client and throws an assertion: > > 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 > > I am running proton v0.8 (debug build). Running in lldb I can see whats > failing: > > frame #0: 0x000000010002cef4 > libqpid-proton.2.dylib`pn_message_decode(msg=0x0000000100204c00, > bytes=0x000000010101d800, > size=0) + 36 at message.c:656 > 653 > 654 int pn_message_decode(pn_message_t *msg, const char *bytes, size_t > size) > 655 { > -> 656 assert(msg && bytes && size); > 657 > 658 pn_message_clear(msg); > 659 > (lldb) p msg > (pn_message_t *) $0 = 0x0000000100204c00 > (lldb) p bytes > (const char *) $1 = 0x000000010101d800 "" > (lldb) p size > > *(size_t) $2 = 0*(lldb) > > When I inspect the messages in Wireshark I can see it flags malformed > packet. Following is from the send client to the broker. > > > *Running the same clients to a C++ Qpid Broker v0.32, however, there are > no issues and the data is received in the recv client fine*. The qpidd > is running vanilla with —topic-pattern parameter. > > Have checked the following combinations with large payloads (ruling out > different MTU on loopback vs active interfaces) > > send (mac) —> Java Broker (loopback mac) —> recv (mac) : Fail > send (mac) —> Java Broker (vnic linux) —> recv (mac) : Fail > send (linux) —> Java Broker (loopback linux) —> recv (linux) : Fail > send (mac) —> C++ Broker (vnic linux) —> recv (mac) : Pass > send (linux) —> C++ Broker (loopback linux) —> recv (linux) : Pass > > Wanted to check whether anyone else has experienced this? Something > configuration based? I am not that familiar with QPID brokers so not > ruling out something I haven’t setup in Java that’s not needed in C++. > > Any help or guidance would be greatly appreciated before I go down a > rabbit hole. > > Thanks > > Phil > > > >
