activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <tb...@alumni.duke.edu>
Subject RE: Problem With Remote Debug OF Message Broker
Date Thu, 15 Sep 2016 02:48:38 GMT
Nothing on that one either, so I assume they're being stripped off
somewhere along the way.  Can you put the screenshot online (either on a
site you have an account on that allows that, or on something anonymous
like imagebin.ca) and send the link?

Tim

On Sep 14, 2016 10:32 AM, <Michael.CTR.Tarullo@faa.gov> wrote:

Sorry about that.  I thought I attached it.  I'll try again here.



Michael Tarullo
Contractor (Engility Corp)
Software Engineer
FAA WJH Technical Center
(609)485-5294

-----Original Message-----
From: tbain98@gmail.com [mailto:tbain98@gmail.com] On Behalf Of Tim Bain
Sent: Wednesday, September 14, 2016 2:10 AM
To: ActiveMQ Users
Subject: Re: Problem With Remote Debug OF Message Broker

Mike,

You referenced a screenshot that showed behavior that wasn't standard for
debugging, but it wasn't attached.  Could you share that again?  I've
assumed in the rest of this response that the debugging session is working
fine but that you're simply not hitting your breakpoint, but if what you
mean is that the debugger itself isn't attached properly, we might need to
go down a different path.

The ActiveMQConnection class is used on the client side of the connection,
but I don't believe it's used on the broker side.  So I think that you
attached a breakpoint that would have been hit if you'd attached to your
client process, but won't be hit while you're attached to the broker.

To step through the logic of a client connection being established while
attached to the debugger, you should be able to set a breakpoint on the
addConnection() method of whatever concrete class your broker is using that
implements the Broker <https://git-wip-us.apache.
org/repos/asf?p=activemq.git;a=blob;f=activemq-broker/src/
main/java/org/apache/activemq/broker/Broker.java;h=
87cb3bcd2fabc54e8df16c426661e582631159e4;hb=refs/heads/master>
interface (for me it's always been ManagedRegionBroker <
https://git-wip-us.apache.org/repos/asf?p=activemq.git;
a=blob;f=activemq-broker/src/main/java/org/apache/activemq/broker/jmx/
ManagedRegionBroker.java;h=ddd1a1745fc46e203d02179011db0a
bd04b50d5c;hb=refs/heads/master>,
but I think that which class is chosen at runtime depends on which options
you have enabled in activemq.xml, so it could be a different class for your
config).  I haven't debugged this method specifically (I was always more
interested in watching the handling of messages than the connection setup
or teardown logic) and I don't have access to one at the moment to be able
to confirm, but I'm pretty sure that method will be hit during the
establishment of a client connection.

One thing that's frustrating about versions before 5.8.0 is that the
activemq-core JAR has a grab-bag of classes that includes some classes that
are used on the broker and some that's used on the client, and it's not
always intuitive where a given class is used.  In 5.8.0, a lot of the code
that was broker-only or client-only was split into the activemq-client and
activemq-broker JARs (here's an illustration <http://grepcode.com/search?
query=activemqconnection&start=0&n=>, for the ActiveMQConnection class you
were setting your breakpoint on; you can see that it was in activemq-core
until 5.7.0, but moved to activemq-client in 5.8.0), so if you're ever not
sure, you can search GrepCode to see which JAR it was in after 5.8.0.

One other thing that's frustrating for debugging ActiveMQ is that if you're
trying to follow the handling of a message on the broker, you pass through
a LOT of delegates/facades for the onMessage() method that just call
another class's onMessage() method.  Often the stack will have a bunch
(it's been a while, but I remember in the ballpark of 6 to 12 in a row),
and it's really tedious to step through them one after the other,
especially with the race against the timeout clock that I mentioned in my
first response.  So I would frequently find I had to step through it once
to figure out what the code path was (living with the fact that my client's
connection to the broker would be timed out and would immediately reconnect
as soon as I let it run again), and then take off that breakpoint and put
it in the couple of interesting methods I found when I walked through the
code, so I could quickly jump from the one to the other without walking
through all those onMessage() methods.

Tim

On Tue, Sep 13, 2016 at 10:11 AM, <Michael.CTR.Tarullo@faa.gov> wrote:

> So I've set my breakpoint in the wrong function of the wrong class?
>
> Michael Tarullo
> Contractor (Engility Corp)
> Software Engineer
> FAA WJH Technical Center
> (609)485-5294
>
>
> -----Original Message-----
> From: tbain98@gmail.com [mailto:tbain98@gmail.com] On Behalf Of Tim
> Bain
> Sent: Tuesday, September 13, 2016 11:31 AM
> To: ActiveMQ Users
> Subject: Re: Problem With Remote Debug OF Message Broker
>
> I would expect start() to be called when the broker starts (hence the
> name) not when a client connects.  If you really want to debug that
> method, there is an option you can set on the debug port that prevents
> the application from running until a debugger attaches.  You can find
> nore details via Google.
>
> I'd recommend figuring out what part of the code you think the problem
> is in, and set the breakpoint there.  Don't try to step through the
> entire codebase looking for the problem; it'll take too long.  And be
> forewarned that pausing some of the code becomes a race against time
> because there are timeouts on some code paths, and if you take too
> long it'll time out and the behavior may change.
>
> Tim
>
> On Sep 13, 2016 7:41 AM, <Michael.CTR.Tarullo@faa.gov> wrote:
>
> I have been assigned to track down a problem that requires debugging
> of the message broker.
>
>
>
> For this particular situation we are running version 5.5.1 of ActiveMQ.
>
>
>
> I downloaded the source code for version 5.5.1 of ActiveMQ and
> imported it into an Eclipse project I created for this purpose.  I
> then created a remote debugging configuration.  I set a breakpoint on
> the first line of code in the start() function of ActiveMQConnection.
> I then start my message broker, start my Eclipse debug configuration
> and then start a JMS client app (i.e. message consumer).  I can see
> from the messages I display in my client (consumer) app that it makes
> a connection to the message broker, but the breakpoint is never hit in my
Eclipse debug session.
>
>
>
> I selected the start() function because it was the function I was most
> sure would be called by simply connecting to the message broker from a
> client.
>
>
>
> Is there something I’m doing wrong to try to walk through the message
> broker code?  Should I be setting breakpoints in different classes?
>
>
>
> As an additional piece of information for anyone who decides to help
> with this I am attaching a screen shot of my Eclipse debugger taken
> well after my JMS client has connected to the message broker.  As you
> will see, the tab in Eclipse that usually displays the source code is
empty.
>
>
>
> Thanks in advance for helping with this.
>
>
>
> Mike
>
>
>
> *Michael Tarullo*
>
> Contractor (Engility Corp)
>
> Software Engineer
>
> FAA WJH Technical Center
>
> (609)485-5294
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message