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=ddd1a1745fc46e203d02179011db0abd04b50d5c;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.taru...@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: tbai...@gmail.com [mailto:tbai...@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.taru...@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 >