Debugger interface fails to open
Check that the debugger daemon is running (jdebug_sui.exe). If it is not
running, select File > Restart debugger. Then, run your
client application.
If the debugger still does not appear, you might have a port conflict. The following three values must match:
For WebSphere Application Server, Version 3.02 or earlier: If you have multiple clients interacting with the same server, you must start an instance of the OLT Client Controller on each client, and specify the same host name on the Remote Debugger page (this should be the host name of the machine on which you started the debugger daemon).
Debugger ignores second application
When you have a multi-user host talking to a single application server, the
first client application to gain control of the debugger retains control
throughout its run. The debugger ignores the second application. To debug object
method calls from the second client, you must bring down the application server
and start the second application on its own.
Debugger fails when debugging AIX client
When debugging an AIX client directly, memory limitations may cause the
debugger to fail. You can avoid this problem by adding the following lines in
the login script file (.profile):
ulimit -d unlimited # to reset limits on data size
ulimit -m unlimited # to reset limits on physical memory
ulimit -s unlimited # to reset limits on stack size
this ensures that usage limits are cleared in each window you open. In addition, you should keep your virtual memory paging space as large as possible. To check current paging space, enter lsps -a on a command line.
Debugger is extremely slow when there is no
network connection
If you are using the Microsoft Loopback Adaptor on a laptop, or are otherwise
operating in disconnected mode, and the debugger takes 10 minutes or more to
open on every request, remove any DNS entries from your TCP/IP settings.