JRebel Debugger Proxy

JRebel Debugger Proxy (JDP) solves performance problems by connecting an IDE to a remote application being debugged in the IDE.

If the remote application is launched with JRebel Agent, the following issues may occur during debugging:

• Thread stacks contain methods and classes that are not in the original class

• Classes contain methods and fields that are not in the original class

• Added methods and fields don’t appear

• Added methods have different names or arguments than the class file

• Inspect or display does not work for added methods and fields

• Stepping through instrumented bytecode may navigate to synthetic lines that don’t exist in the class file, or generated methods or classes

• Breakpoints may fail to trigger, before or after a class is reloaded

• Class reloading through debugger HotSwap may fail, even though JRebel claims the class is reloaded

The JRebel plugin allows debugger instrumentation to fix these issues. You can debug the JRebel-instrumented remote application similarly to a plain remote application.

Important

If network latency is 20+ ms, debugging operations (such as populating the Variables view in the IDE debugger UI) may be slower than debugging without JRebel due to extra network traffic for hiding JRebel-specific information. The debugger instrumentation is implemented in the plugin, and the extra traffic must travel from the IDE to the target process.

JDP runs alongside the remote application on the same host. The IDE connects to JDP instead of the remote application. JDP mediates all debugger traffic between the IDE and the remote application. The logic implemented in JDP hides JRebel-specific details from the IDE. Since the extra traffic required to serve this purpose stays on the remote host itself, a slow network does not impact performance.

• Starting with JRebel Agent
• Starting manually
• IDE configuration
• Troubleshooting
• Logging