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]

Reply via email to