qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Framing error /w qpid 0.28
Date Thu, 29 Jan 2015 14:36:43 GMT
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message