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.
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.