Getting Started with Remote Debugging (SAP Library

Getting Started with Remote Debugging

Debugging contributes to the efficient development of applications. In the context of J2EE Engine applications, remote debugging has very special aspects. The implementation of debugging is burdened by the cluster capabilities of the J2EE Engine. A J2EE Engine can consist of multiple processes (nodes) forming a cluster. Processes in the cluster avoid overloading by sending incoming service requests to the process with the least load. This is called the load-balancing mechanism. The load-balancing mechanism, however, means that we never know for certain which node will handle a particular request.

The problem comes with reaching breakpoints in the application being debugged. When the execution of such an application reaches a breakpoint, the Java Virtual Machine of the application is stopped. When the application runs on the J2EE Engine, this means that the entire server process which is handling the request will stop too. One server process may be processing many client requests at a time. So if the process is blocked because a debug request reached a breakpoint, all other requests will be blocked too, as they run in the same VM. If some of them are productive requests (meaning a request from a real user), this will be a problem. Furthermore, with the J2EE Engine, the entire cluster may be stopped. The reason is that the rest of the processes may wait for a response from the node processing the request – this could be cluster communication using the same database, holding a cluster-wide lock. For productive systems, this may be a critical problem.

The solution is to appoint one or more cluster nodes for debugging, and to separate them from the rest of the cluster. The rest of the processes can continue their work as productive processes during the debugging, That is, they will continue servicing customers.

The isolation of debug nodes involves the following stages:

...

1. Defining the debuggable and productive nodes

This process defines, purely informatively, which nodes can be debugged and which cannot. Debuggable nodes can be debugged, and productive nodes can never be debugged. This does not automatically make a node ready for debugging, however.

2. Restricting the cluster’s load balancing mechanism

This process defines that the process will no longer participate in the load-balancing mechanism. The node will not handle client requests any more. Hence, the breakpoints will not disturb productive requests.

3. Enabling Debug mode

This changes the mode of operation from Run to Debug.

4. Reserving the nodes for debugging

This excludes the nodes from any communication with the other server nodes. This step ensures that the breakpoints will not disturb the whole J2EE Engine but only the current node. But this also means that the application will not be updated on the other nodes when you update it on the node in the debugging session, and vice versa.

Caution

While you are debugging, if you change the Java source code and save it, the changes are automatically reflected on the J2EE Engine.

Debugging Scenarios

The following tables show the specifics of remote debugging for each possible configuration.

Scenario

Description

Single server configuration

We have single server configuration when there is only one server host in the cluster. You do not need to restrict the cluster communication and load balancing because there are no other processes / nodes in the cluster – that is, you may use a faster procedure for enabling debug mode. For more information, see Debugging in a Single Server Configuration.

Cluster configuration

We have cluster configuration when the J2EE Engine consists of more than one server node. The server nodes can be located in a single physical machine or (more often) on different hosts (WAN or LAN scenario).

In a cluster configuration, you need to take all previously stated steps to prepare the J2EE Engine for debugging. For more information, see Debugging in a Cluster Configuration.

Note

If you are debugging a J2EE Engine hidden behind a firewall (WAN scenario), you need to use the SAP Router technology to enable debug messages to be transmitted through the firewall. For more information, see the Remote Debugging via SAP Router section of the SAP NetWeaver Developer Studio help.

The Debugging Process

The SAP NetWeaver Developer Studio provides tools for debugging your Java applications. For this purpose, you can set breakpoints in the Java source code.

To enable debugging, the J2EE Engine must be running and debugging must be activated. By default, debugging is deactivated on the server. Therefore, you must activate debugging on the relevant server node.

To start the application in debugging mode, you must create a reusable debug launch configuration and then use the Debug perspective to analyze the code.

This graphic is explained in the accompanying text

For information on using the Debugger, refer to the Java Development User Guide (Help ® Help Contents), in particular the topic Debug view.