Is there any way to locally debug/step through code in a snap in? I see options such as putting a server in debug mode, but it doesn't really state what this does and it's implications.

Hi Michael, you've found a hole in our documentation that we're going to fill. Here's what I think I know. I'll confirm with you when the experts confirm my understanding.

You saw that our documentation speaks two "Breeze Actions" supported via the Eclipse plugin: "Enable Debug on Selected server(s)" and "Disable Debug on Selected server(s)". I believe that enabling debug does the following:
• Port 8787 is opened in the Breeze firewall
• Websphere shuts down (all Breeze snap-ins will stop)
• Websphere restarts having bound port 8787 on the "Management NIC" to its debugger port

You should then be able to attach the Eclipse debugger to port 8787 on the management IP address.

There is also a CLI command called "enableDebugCE" that does the same thing (in fact this is the command invoked by the Eclipse plugin. I assume there's also a "disableDebugCE".

If I got anything wrong here, I'll let you know tomorrow. There should be no negative ramifications to leaving debug mode on all the time in the lab. You wouldn't want to do this in production due to the security risk (incoming connections to that port are not authenticated in any way).

I have confirmed that I know what I thought I knew. :-)

Thanks for the info. It doesn't seem to work, or at least not reliably. I did get it to connect 1 time, and the first time it hit a breakpoint, it would not step. I clicked continue which allowed the call to process, but it would not sync with the code. Continue to get these errors on retry:

Failed to connect to remote VM. Connection timed out.
Timeout occurred while waiting for packet 2365.

Failed to connect to remote VM. Connection refused.
Connection refused: connect

That's unfortunate. Which mechanism did you use to enable debugging? CLI or Eclipse plugin? Have you tried enabling again (maybe using the other method) to see what the behavior is?

I did it via the command line on the server itself. Will give it a shot using eclipse plugin to see what happens.

No luck unfortunately. Just constant connection refused.

My process was :

clean package and deploy service with eclipse plugin.
added remote debug to eclipse option via Run -> Debug configurations, Remote Java application, enter device name and port 8787.
Open eclipse breeze plugin, and select only server I am testing with and save.
right click project -> enable debug on selected server

At this point I see the service shut down as server restarts.
I wait until I see entries in server log for server.startup to be sure server is started.

Right click on project and debug as -> select entry created previously.

Eclipse tries, gets to 92% on progress bar, and eventually times out.
Each successive try produces connection refused.

Hi Michael, we're working on coming up with some suggestions for how to diagnose this issue. The only suggestion that I've gotten thus far is to ensure that you only have one Eclipse instance trying to connect to the debugger port. Only one concurrent connection is allowed. Hopefully we'll have more for you later today or tomorrow.

Here are some things you can try to see where the problem might lie:

ce fwall show 8787
This will tell us whether port 8787 has properly been opened on the O/S firewall.

netstat -ap
You can check this to see if the WebSphere Java process has bound to port 8787

If both of those look good, you may want to try a tshark trace to see if the debugger is correctly trying to connect to port 8787 (TCP SYN message).

I do not see it in the netstat output, but it is in the fwall check. However the netstat output tells me I have to be root to see it all, so it might just not be visible.

ce fwall show 8787
8787 on

netstat -ap >netstat.log
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)

Ok so I got it to connect again, this time not touching anything until something happened. It took several minutes for it to finally show me the processes in the debugger. I set a breakpoint under callIntercepted, made a call, and I could see that it hit my breakpoint. However it never let me step past it or do anything really. I finally just pressed continue to let the call go through. I think it is just so slow that eclipse loses sync with it or something.