Raised https://issues.apache.org/jira/browse/QPID-6651 
<https://issues.apache.org/jira/browse/QPID-6651> 


> On 22 Jul 2015, at 19:33, Philip Preston <[email protected]> wrote:
> 
> Hey 
> 
> Yeah - as I said it was all pretty vanilla - so thought it was unusual.
> 
> I’ll get the logs and open issue.
> 
> I’ll kick the tires on later releases.
> 
> Thanks
> 
> Phil
> 
> 
>> On 22 Jul 2015, at 13:22, Rob Godfrey <[email protected]> wrote:
>> 
>> 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 
>> <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] 
>> <mailto:[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
>> 
>> 
>> 
>> 
> 

Reply via email to