Part 1 : Remote Debugging a Managed Server on Production Weblogic 10.3 Cluster

Printer-friendly versionPDF version

So I had to debug an ADF application issue on a weblogic server running in production mode. It turned out to be an interesting exercise. There were bit of information here and there but nothing definitive that I knew would work for the constellation.

In tackling the problem I am able to summarize my findings as below.

Starting the required Managed Server in Debug mode

It turns out there are 2 options to accomplish this. In my opinion both of these options could be consider clean enough. Whereby Option 1 should be preferred.

Option 1: Via Weblogic Console

  1. Navigate to your weblogic server's console url ( of the form http://yourservername:port/console ) and login using your credentials.
  2. On the left hand side tree, click to open node "YourDomain -> Environments - > Servers". This will open up the list of your managed servers for that domain.
  3. Click the managed server name from the list you wish to debug.
  4. On the next page belonging to that managed server, click, "Configurations" tab's sub-tab "Server Start".
  5. On the left hand side, there is a "Lock and Edit" button that says "Click the Lock & Edit button to modify, add or delete items in this domain." Click on that.
  6. Now your server configuration becomes editable.
  7. In the "Arguments" text box of this managed server, just add these lines to your existing configuration. "-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n"
  8. The "Lock and Edit" button turns to say "Activate Changes". Click on that. Weblogic Remote Debug Options via WLS Console
  9. Now navigate as below and bounce the server. Shut it down if running or just start it up if already shutdown.

Bounce Managed Weblogic Server


Option 2: Via

This is now an intrusive solution where you have to go on the file system and modify the "" file on the production system. Unless for some reason the above option does not work for you, you might want to go this way. Make a backup of the original file.

Than make open the file on the domain where your managed server is located for e.g. /instance/domains/ There you will find this central file that is called "". This file is used when you start the weblogic server via command line here with "" file or node manager or via the console as we did above, which in turn again uses nodemanager if I correctly understood the doc for my Weblogic server .

To modify it unintrusively add the following tentative line:

export debugFlag

Normally on a standalone instance this would be enough. But remember we are on a server running several managed servers. This runs into port conflicts as the script tries to start all managed servers. You might not be doing this, as you will just bring down one server and than restart it with that change. The others already running won't be affected.

Now notice the "$SERVER_NAME" variable in the script. You could put that to good use for your case and refine the solution to avoid port conflicts like below. (I take no credit for this solution, it is from a colleageue, I can only imagine the pain he went through before coming up with this solution) :

if [ "{$SERVER_NAME}" = "YourManagedServer_1"  ] ; then 
        export debugFlag

Or you can be even more creative and assign new ports to every server in maybe increments on port clashes.

Thats it, than start the server via your WLS console. You should be good to go.


Verifying if debug port is opened

Now there are a couple of ways to verify if your debug port (we specified 8453) is enabled or not.

From server machine

netstat -an | grep -i 8453
tcp        0      0      *                   LISTEN

nc -z 8453
Connection to 8453 port [tcp/*] succeeded!

pgrep -fl 8453
28350 /jdk6/bin/java -jrockit -Xms256m ...... -Xmx1680m -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n  ........

From your development remote machine

  1. Directly connect a remote debugger to the port from eclipse/netbeans/jdev. If it connects your all good to go. Debug your issue and enjoy life.
  2. Or with below commands
nc -z 8453
telnet 8453

If your one of those lucky ones, for whom things just work, you can stop here. But if for some reason your development machine cannot connect but your server is showing port is open and listening, you might want to go on to my 2nd article here.



thank you. It was helpful

Add new comment