HI everyone,
attached you can find some logs & dumps depicting the problem. The scenario is:
1 process ("replay") reading the data for the message DB, create the
qpid message, send it to the given topic, exit.
2 processes ("qpidSniffer") reading all messages from said topicFirst both qpidSniffer processes are started, then replay. All this ran with qpid 0.30; as I said before I encountered the same behaviour using 0.28. There are three different outcomes: 1. both read the message 2. only one does, the other produces a framing error 3. both produce the framing error. I attached the data for three runs. The first set The logs attached here show outcome 2, that is: one reads the message, one doesnt. The first set of logs (prefix: 1_ ) are the amqp api logs (created with a qpid::messaging::Logger, log level trace+). In this run, qpidSniffer2 produced the error while qpidSniffer accepts the message. 1_stdout* shows the output of the three programs (this contains a textual representation of the message...) The second set of logs shows the output of the programs using PN_TRACE_RAW=1. In this run, qpidSniffer2 managed to read the message while qpidSniffer did not. PN_TRACE_RAW did not work when I had the qpid logger activated... hence the second set). The peculiar thing here was: if replay only sends the one message described above, not output at all is created using PN_TRACE_RAW; not even the initial handshake with the broker. Only if I activate out internal log / info messages (just small test messages logging to an info topic) anything is shown. This can be seen in 2_*_with_additional_messages.txt. The third set contains a filtered .pcap file or a transaction (recorded as an afterthought, hence another run). There are quite some errors shown by wireshark, but I do not know if the included filters that come with wireshark can be trusted or not so I hope this gives you enough to work with. Thanks a million for the time and work you put into this! Best regards, Daniel 2015-01-28 21:42 GMT+01:00 Daniel Wenske <[email protected]>: > Ah, sorry... yeah, it also is the C++-Broker. Will try the PN_TRACE_RAW > tomorrow at work & send you the details then. > > 2015-01-28 20:45 GMT+01:00 Gordon Sim <[email protected]>: >> >> On 01/28/2015 07:42 PM, Gordon Sim wrote: >>> >>> On 01/28/2015 06:39 PM, Chuck Rolke wrote: >>>> >>>> It looks like the C++ broker from the trap address >>>> qpid-0.28/cpp/src/qpid/messaging/amqp/ConnectionContext.cpp:717 >>> >>> >>> That's the client. Is it also using the Qpid c++ broker? Or is it some >>> other broker? >>> >>> From the error, it looks like the proton library used by the client got >>> something it felt was invalid. >>> >>> Can you get a tcpdump from an interaction causing a failure? That should >>> highlight the problem clearly. (Or else a reproducer). >> >> >> Alternatively if easier, just export PN_TRACE_RAW=1 before running as >> well. That way we get the raw bytes received which hopefully will shed more >> light on the problem. >> >> >>> Are there any errors in the broker logs (grep for error if it is qpidd). >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >
qpid_0.30_framing_error_logs.tar.gz
Description: GNU Zip compressed data
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
