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