qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Rolke <cro...@redhat.com>
Subject Re: Project Adverb - Illustrated AMQP decoding for real-world scenarios
Date Wed, 25 Jun 2014 22:17:10 GMT
Yes, there's a ton more analysis one could do.

For this baby step I specifically didn't what to do anything that Wireshark already does or
can do. Also, the pages I'm showing are produced by a lowly .xsl script which works a certain
magic but isn't capable of all that much in one pass.

I tried capturing the output of a proton self test run and the results are humbling. First,
wireshark doesn't decode all AMQP automatically unless it's going to port 5672. In self tests
not much goes to port 5672. After manually setting DecodeAs to likely candidate port pairs
the generated html files grow pretty big (2000+ display lines). And, as you point out, there's
tons of information that isn't relevant and there's no way to focus on what you want. One
thing lacking from the current scheme is a way go select TCP flows. In the selftests all the
flows are flattened together and it's nearly hopeless finding the flow you want. 

-Chuck

----- Original Message -----
> From: "Alan Conway" <aconway@redhat.com>
> To: users@qpid.apache.org
> Sent: Wednesday, June 25, 2014 12:12:16 PM
> Subject: Re: Project Adverb - Illustrated AMQP decoding for real-world scenarios
> 
> On Mon, 2014-06-23 at 14:16 -0400, Chuck Rolke wrote:
> > Here's a link to get to the results.
> > 
> > http://people.apache.org/~chug/Adverb/
> > 
> 
> That is Really Cool.
> 
> It has immediate and obvious application as a learning and debugging
> tool for examining short AMQP sequences to see if what I think is
> happening is really happening.
> 
> I'd love to have something like that to analyse trace log output direct
> from qpidd. I could rig up wireshark but I'd like to be able to see this
> in context of other stuff that's happening in the qpidd logs. However
> doing this independently at the protocol level is a good idea as it
> doesn't tie you to a particular AMQP-speaking entity.
> 
> The thing that is hardest about debugging trace logs is finding the
> stuff you are trying to find in thousands of lines of irrelevant
> chatter. What would make this truly awesome is a flexible way to select
> bits of the conversation. Things like "just show me outgoing subscribes
> and incoming transfers for queue X and all the transaction performants
> on session Y." I don't know a good way to do that, I just do grep after
> grep after "dammit I grepped out the other thing I need to see" etc.
> 
> I get the feeling there's potential for something smarter and easier to
> use here but I'm not sure how to present it as something clickable on a
> web page. You really want to be able to explore:
> - Hmm, looks like that's the session I'm interested show me that session
> - OK narrow it down to just the tx-12345 queue
> - Something else is going on, lets see all the subscriptions to that
> queue.
> - OK, now lets see all the transfers for that queue from just these 2
> sessions...
> etc.
> 
> Anyway nice job!
> Alan.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message