This does not help, still getting the same error... 2015-01-29 15:36 GMT+01:00 Gordon Sim <[email protected]>: > On 01/29/2015 02:20 PM, Daniel Wenske wrote: >> >> 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 topic >> >> First 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! > > > It looks like perhaps a bug in the sasl security layer encoding. Try setting > the "sasl_max_ssf" connection option to 0. If that still fails try with > "sasl_mechanisms" set to "PLAIN". That will at least confirm the source of > the problem. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
