US20070055957A1

US20070055957A1 - Remote debugging proxy

Info

Publication number: US20070055957A1
Application number: US11/221,667
Authority: US
Inventors: Richard Birenheide; Eckart Langhuth; Matthias Metzler
Original assignee: Individual
Current assignee: SAP SE
Priority date: 2005-09-07
Filing date: 2005-09-07
Publication date: 2007-03-08
Also published as: US8806442B2; US20070055958A1

Abstract

A system and method for a remote debugging proxy. An embodiment of a method for debugging a target system application includes receiving notification of an event regarding the target system at a first proxy component via a second proxy component. The method further includes receiving data regarding the event at the first proxy component via the second proxy component, and storing the data in a cache memory.

Description

TECHNICAL FIELD

Embodiments of the invention generally relate to the field of client/server systems and, more particularly, to a system and method for a remote debugging proxy.

BACKGROUND

In the development of computer applications, it is necessary to efficiently and effectively detect errors in order to make corrections and complete development. This debugging process is an extremely important part of software product maintenance, and often requires a large portion of the overall time and effort that is expended on the application.
In certain environments it may be possible to debug a system remotely. For example, a Java application may be debugged remotely in the Java platform debugger architecture (JPDA). In this way, an application that is running on a remote client virtual machine may be debugged via a connection with a debugging system.
However, a connection between a remote client and a debugging system may slow the developing process. This border or boundary between the local and remote systems may have a low bandwidth and the response time over such connection may be high. In such circumstances, the remote debugging process may become very time intensive. In, for example, the JPDA, every transaction between the client and server in a conventional protocol requires a roundtrip request and response cycle. The result may be a slow debugging process that hampers application maintenance.

SUMMARY OF THE INVENTION

A system and method for a remote debugging proxy are described.
According to a first embodiment of the invention, a method for debugging a system includes receiving notification of an event regarding a target system at a first proxy component. The first proxy component requests information related to the target system. The information is transferred from the first proxy component to a second proxy component, and the information is stored in a memory.
Under a second embodiment of the invention, a debugging system includes a debugging component, a first proxy component coupled with the debugging component, and a second proxy component coupled with a target system to be debugged. The second proxy component and the first proxy component are linked by a communication channel. The second proxy component is to collect data from the target system.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example, and not by way of imitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
FIG. 1 is an illustration of an embodiment of a remote proxy debugging system;
FIG. 2 is an illustration of an embodiment of a local proxy engine;
FIG. 3 is an illustration of an embodiment of a remote proxy engine;
FIG. 4 is an illustration of an embodiment of an information collector for a remote proxy engine;
FIG. 5 is an illustration of an embodiment of a JDI connector that may be utilized in a proxy engine; and
FIG. 6 is a flow chart to illustrate an embodiment of remote debugging of an application by proxy.

DETAILED DESCRIPTION

Embodiments of the invention are generally directed to a system and method for a remote debug proxy.
In one embodiment of the invention, a software development system, such as an integrated development environment (IDE), remotely debugs an application through use of a proxy system. In one embodiment, a debugging system includes a proxy for processing information requests. In a particular embodiment, a debugger proxy includes a local proxy engine for the debugger and a remote proxy engine for the target system that is being evaluated. A remote debugging proxy obtains information regarding a target system and transfers the information to a local debugging proxy. A local debugging proxy receives information regarding a target system, caches the information, and retrieves the information from the cache when a request for information is received.
In application development, a remote debugging process includes a debugging system that performs remote debugging operations on a target system. In an embodiment of the invention, a remote debugging process includes a proxy system for the transfer of information. In one embodiment, communications between the debugging system and the target system are rerouted through a proxy component on the debugging side (which may be referred to as a local side proxy) and a proxy component on the target side (which may be referred to as a remote side proxy). In this embodiment, the remote side proxy collects context depended information regarding the target system, compresses the information, and sends the information to the local side proxy. The local side proxy caches the information, and can then quickly respond to many requests for information by accessing the cache, thereby eliminating many communications that would otherwise be transferred across the boundary between the local and remote sides.
In a particular example, a Java remote debug proxy system may be provided for a Java process that debugged via a remote connection. A debugging operation may be implemented using the Java platform debugger architecture (JPDA). (Java Platform Debugger Architecture, JPDA 1.0) In such architecture, a virtual machine (which is generally a portion of a larger system that appears to have a separate processor) is debugged by a debugging component, or debugger (a system that is intended to identify or fix errors, or bugs, in applications). A debugger may be included in an IDE or other development system. The elements of a debugging system may include a front-end software protocol or module, a back-end software protocol or module, a communication channel, and a user interface (UI). The virtual machine and the back-end software protocol are known as the debuggee (or the remote side), while the front end software protocol and the user interface may be referred to as the debugger (or the local side). The back-end is responsible for communicating requests from the debugger front-end to the debuggee/virtual machine and for communicating the response to the requests to the frond end. The communications are transferred across a communications channel that links the front-end with the back-end of the debugger system, and with the details of the communication channel varying with the implementation.
The JPDA provides interfaces and protocols for communication that define the debugging services a virtual machine provides, define the high-level interface for remote debugger applications, and define the communication between the debuggee and the debugger processes across the communication channel (which may be referred herein as a border or boundary between the local and remote sides). The JPDA consists of three layers, the layers being:
(a) Java Virtual Machine Debug Interface (JVMDI)—The interface defining the debugging services that a virtual machine provides.
(b) Java Debug Wire Protocol (JDWP)—The protocol to define the communications between the debugger and the target virtual machine (or debuggee) processes. The communication over the communication channel is specified by the JDWP.
(c) Java Debug Interface (JDI)—The high-level Java language interface for use in writing remote debugger applications. The user interface is a client of the JDI.
In conventional remote debugging processes, debugging can be slow, particularly if the connection across the communication channel has a high response time. In such an operation, the performance of the system may suffer because of the need to make numerous transmissions across the slow connection. In one example, a Java application is debugged remotely via a JDWP communication channel between the Java application and a debugger. The JDWP allows a debugger to work either in a different process on the same computer or on a remote computer. However, the JDWP is a low level request and response system. In such a system, any user interface that requires detailed information about the target system state is thus required to collect this information via multiple round trip communications across the boundary between the local-debugging side and the remote-target side.
In a remote debugging process, the types of communication that are authorized by the protocol describing the communication channel may be very limited. Because of this, numerous communications may be required to accomplish debugging objectives. For example, in JDWP operations there are two basic types of packets, which are command packets and reply packets. In this system, any debugging operation relies on the use of multiple commands and replies. The command packets may be sent by either the debugger or the target virtual machine. The debugger uses command packets to request information from the target virtual machine or to control program execution. The target virtual machine uses command packets to notify the debugger of an event in the target virtual machine, which may include a breakpoint or an exception.
In the JDWP process, a reply packet is only sent in response to a command packet. A reply packet will indicate the success or failure of the command and may carry data that was requested in the command. An event sent from the target virtual machine to the debugger generally does not require any reply. The JDWP is an asynchronous protocol, and multiple command packets may be sent before a reply is received. The format of each packet is set by the JDWP, with each packet containing a header of a set length with specified information, followed by data, if any.
In a remote debugging operation using JDWP, a debugging process will require multiple requests from the debugger to obtain data regarding the target system. Each request is in the form of a certain JDWP command packet. The target system is required then to reply to each command using a JDWP reply packet. Thus, there may be a large number of requests and responses, each requiring a time-consuming round trip communication across the interface boundary between the debug side and the remote side.
In an embodiment of the invention, a remote debugging proxy system may reduce the number of round trip communications required for processing and the total amount of data transferred between the local and remote sides, thereby increasing the efficiency of the debugging operation. In the embodiment, the communications are rerouted through proxies, with a proxy engine on the local side and a proxy engine on the remote side. The remote side proxy collects context depended information about the target system, and then compresses the information and sends it to the local proxy. The local proxy stores the information and retrieves the information as needed, thereby avoiding certain round trip requests across the boundary between the remote and local sides.
In one example, a target virtual machine may send a message such as a suspend event indicating that processing is suspended. Upon receiving such event, the remote proxy collects additional information regarding the current event. The remote proxy then compresses the collected information to minimize the time required for transmission, and sends the information to the local proxy via a JDWP-extension command. The local proxy receives the command, and identifies the command as a JDWP-extension command. The local proxy decompresses the information and stores the information in a cache and sends the original suspend command on to the debugger. The debugger receives the suspend command and starts a user interface update. Based on the user interface update, the debugger may send one or more commands to request more information, with the local proxy receiving the request commands from the debugger. In response, the local proxy will retrieve a reply from the cache if the needed information has been stored in the cache. If the reply to a request is not available from the cache, the local proxy forwards the request to the remote proxy for processing. The remote proxy receives the request and provides the request to the target virtual machine to obtain the needed information, which may then be returned to the debugger via the remote proxy and the local proxy.
FIG. 1 is an illustration of an embodiment of a remote proxy debugging system. In this illustration, a debugging component illustrated as debugger 105, which may include a virtual machine or other system, is remotely debugging an application on a target system 110, or debuggee. In a Java platform architecture environment, the debugger includes a front end software protocol or module, which implements the high level JDI, and a user interface or UI. The debuggee includes the virtual machine that is the target of the debugging operation, and a back-end software protocol or module. The debuggee implements the JVMDI for communication with the virtual machine However, the remote debugging process requires communications across a border 115, such as over a communication channel in the JPDA. The border 115 may be a slow (high ping, low bandwidth) boundary that thus slows debugging performance.
In an embodiment of the invention, the remote debugging process is implemented through use of proxy engine operations. In an embodiment, the debugger 105 (which is on the “local” side of the border 115) is coupled with a local debug proxy 120 and the target system (on the “remote” side of the border 115)) is coupled with a remote debug proxy 125. The debugger 105 and local debug proxy 120 may make up a fast LAN (local area network) or a single virtual machine 130. The remote debug proxy 125 and the target system 110 may make up a fast LAN. The local debug proxy 120 and the remote debug proxy 125 communicate across the boundary 115.
In an embodiment of the invention, the local debug proxy 120 obtains information regarding the target system from the remote debug proxy 125 and caches such information for future requests. For example, the target system 110 may issue a suspend event, which may trigger a request from the remote debug proxy 125 to collect more information. The information is received by the remote debug proxy, compressed if necessary, and transferred to the local debug proxy 120. The local debug proxy 120 stores the information in a cache or other memory for future use, and sends on the suspend event to the debugger 105. When the debugger 105 requires information for the debugging process, the request is directed through the local debug proxy engine 120. If the local debug proxy 120 has information to respond to the request stored in the memory, the desired information is retrieved from the memory of the local debug proxy 120. If the local debug proxy has not cached the information that is needed to respond to the request from the debugger 105, then the local debug proxy 120 will forward the request to the remote debug proxy 125, which will then operate with the target system 110 to collect the information needed for the reply.
FIG. 2 is an illustration of an embodiment of a local proxy engine. The local proxy engine 205 is used in remote debugging of applications. The local proxy engine 205 may, for example, represent the local debug proxy 120 shown in FIG. 1. In this illustration, the local proxy engine 205 includes a first connector 210, which may be coupled with a debugger (such as debugger 105 in FIG. 1, not shown in FIG. 2), and a second connector 215 which may be used to communicate with a remote proxy (such as remote proxy engine 125 in FIG. 1, not shown in FIG. 2) that is coupled with a target system or virtual machine. The connectors may be JDI connectors. The local proxy engine further includes an output controller 220, an input controller 225, and a communication protocol cache 230. The local proxy engine 205 may also relate to a proxy configuration 235 to direct the configuration of the engine.
The input controller 225 listens for commands received by the first connector 210 from the debugger. If a message is received by the local proxy engine 205 at the first connector 210, the message is transferred to the input controller 225. If the message is a proxy configuration command, then the input controller 225 will handle the configuration 235. If the message is a JDWP command from the debugger, then the input controller 225 will attempt to obtain the reply from the communication protocol cache 230. If the required information is found in the cache 230, then a reply is sent to the debugger via first connector 210. If the information is not found in the cache 230, then the command is sent to the debuggee (such as via the remote proxy engine 305 in FIG. 3) via second connector 215.
The output controller 220 listens for commands received by the second connector 215 from the target or remote proxy. The output controller 220 will analyze any received message and take necessary actions, including unpacking data, storing the data in the communication protocol cache 230 if appropriate, and related actions. The output controller 220 will send an event or reply (depending on the command content) to the debugger via the first connector 210. If the local proxy engine 205 receives information in connection with an event that has occurred, then the information is directed to the output controller 220, which may then save the information in the communication protocol cache 230 for use in addressing future inquiries.
In an example, the debugger may send a command requesting information in connection with an event, the command being received at the first connector 210. The command is directed to the input controller 225, which interprets the command as a JDWP command. The output controller 220 accesses the communication protocol cache 230 and determines whether the information is present in the cache 230. If the information is present, then a reply containing the information is transferred to the debugger via the first connector 210. If the needed information is not present in the cache 230, then the request command is directed from the output controller 220 to the remote proxy engine via the second connector 215. A reply command may then be received at the second connector 215 and be directed to the output controller 220. The output controller can then interpret the received reply, and then provide the reply to the first connector 210 for transmission to the debugger.
FIG. 3 is an illustration of an embodiment of a remote proxy engine. In this illustration, a remote proxy engine contains a first connector 310, which may communicate with a local proxy engine, such as local debug proxy 120 in FIG. 1, and a second connector 315, which may be coupled with a target system, such as target system 110 in FIG. 1. The connectors may be JDI connectors. The first connector 310 provides received commands to an input interpreter 330, and sends commands that are received from an output interpreter 325. Between the input and output interpreters and the second connector 315 is an identity mapper 340, which includes an identity map 345. In one implementation, the remote proxy engine also includes an information collector 320 to receive all input and output commands and provide these as needed to the identity mapper 340. The remote proxy engine may also include a proxy configuration 350.
In this illustration, a command may be received at the first connector 310. The command would be handled by an input interpreter 330, which will direct the command either to the information collector 320 and the identity mapper 340 if the command is a request for information, or to a command handler if the command is for other actions, such as, for example, proxy configurations. The remote proxy engine 305 also acts in the collection of information to be cached with the local proxy engine. For example, the target device may issue a suspend event, which is received at the second connector 315 and directed through the identity mapper 340 to the output interpreter 325. The output interpreter 325 sends a request to the information collector 320 to collect more information regarding the current event. The information collector 320 determines an information collection strategy for the current event and collects the state information for the target device (which may include but is not limited to thread, stack, and variable information). The collected information is received by the output interpreter 325, and is compressed and sent via a JWCP-extension command to the local proxy via the first connector 310.
In this particular implementation, the identity mapper 340 is used to wrap communications via second connector 315 because JSWP commands are identified via the command ID's. The collection of additional information via second connector 315 from the target brings the ID's into the debugger. The identity mapper is thus used to modify, or “repair”, the command ID's for use by the appropriate components.
FIG. 4 is an illustration of an embodiment of an information collector for a remote proxy engine, such as the information collector 320 of remote proxy engine 305 in FIG. 3. In this illustration, the information collector 405 is coupled with an output interpreter 435 and an input interpreter 440. When an event is received by the output interpreter 435, the output interpreter 435 forwards a request for information collection to the information collector 405. The request is received by an information collection engine 415, which requests an information collection strategy from a strategy manager 420. The strategy manager includes a collection of pending strategies 425. Using the developed strategy, the information collection engine 415 sends the required commands through a connector 410 to the target device for the debugging process. The connector 410 may be a JDI connector.
Further, the input interpreter 440 may receive commands requesting information regarding the target device. A pending request is then added to a request processor 430, which directs the pending request to the strategy manager 420 to develop a strategy for the collection of the needed information.
FIG. 5 is an illustration of a JDI connector that may be utilized in an embodiment of a proxy engine. The JDI connector may include connectors 210 and 215 of FIG. 2 and connectors 310 and 315 of FIG. 3. In an embodiment of the invention, JDI connectors may be included in particular implementation of a remote debugging environment, including use in a local proxy engine and in a remote proxy engine. In this illustration, the connector 505 includes a send queue 510, which may act as a queue of JDI command objects. The send queue is polled by a writer thread 520, which writes the JDI commands to an output stream, which is directed to a socket, illustrated as SocketStream 530. The SocketStream also receives data, with a reader thread 525 reading the data from an input data stream. The reader thread 525 then creates JDI command objects from the data and puts the objects into a received queue 515.
FIG. 6 is a flow chart to illustrate an embodiment of remote debugging of an application by proxy. In this illustration, an event may be received from a target system 605. In order to obtain further information, an information collection strategy is developed 610. The context depended information related to the event is collected at a remote proxy location 615. The information is compressed 620 to minimize the transfer time and is transferred to a local proxy 625. Upon being received at the local proxy, the information is cached 630.
A command requesting information may be received from the debugger used in the remote debugging operation 635. Rather than be sent to the target system, the command is rerouted to the local proxy 640. The local proxy then accesses the cache 645 to determine whether the information is already stored and thus would not need to be obtained from the target system. If the information is contained in the cache 655, the information is retrieved 660 and the information is provided to the debugger 665. The retrieval of the information from the cache avoids the need to send multiple information requests that require roundtrip communications over the communications channel between the debugger side and the remote side. If the information is not contained in the cache 655, then the command will be sent to the remote proxy 665, followed by development of a collection strategy 670 and collection of the needed information 675. The data is routed from the remote proxy to the local proxy 680 and then provided to the debugger 685.
It should be appreciated that reference throughout this specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Therefore, it is emphasized and should be appreciated that two or more references to “an embodiment” or “one embodiment” or “an alternative embodiment” in various portions of this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures or characteristics may be combined as suitable in one or more embodiments of the invention.
Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Claims

1-24. (canceled)

25. A method for debugging a target system application comprising:

receiving notification of an event regarding the target system at a first proxy component via a second proxy component;

receiving data regarding the event at the first proxy component via the second proxy component; and

storing the data in a cache memory.

26. The method of claim 25, further providing forwarding the notification of the event to a debugging component.

27. The method of claim 26, further comprising:

receiving a request from the debugging component for information regarding the target system; and

searching the cache memory for the requested information.

28. The method of claim 27, further comprising transferring the requested information to the debugging component if the information is present in the cache memory.

29. The method of claim 28, wherein the requested information is provided to the debugging component without sending a communication to the target system.

30. The method of claim 27, further comprising transferring the request to the target system via the second proxy component if the information is not present in the cache memory.

31. The method of claim 25, wherein receiving data regarding the event at the first proxy component via the second proxy component includes decompressing the received data.

32. The method of claim 25, wherein the target system comprises a Java virtual machine.

33. A debugging proxy comprising:

a first connector to be coupled with a debugger;

a second connector to be coupled with a proxy for a target computer system to be debugged; and

a memory to hold data regarding events of the target computer system received from the proxy for the target computer system.

34. The debugging proxy of claim 33, further comprising an input controller to receive a request for data from the debugger via the first connector.

35. The debugging proxy of claim 34, wherein the input controller is to search the memory for the requested data.

36. The debugging proxy of claim 35, wherein the input controller is to direct the requested data to the debugger via the first connector if the requested data is present in the memory.

37. The debugging proxy of claim 35, wherein the input controller is to direct the request from data to the second proxy via the second connector if the requested data is not present in the memory.

38. The debugging proxy of claim 33, further comprising an output controller to receive commands via the second connector.

39. The debugging proxy of claim 38, wherein if the command comprises a event regarding the target system then the output controller directs the event to the debugger via the first connector.

40. The debugging proxy of claim 38, wherein if the command comprises data regarding an event of the target system then the output controller directs the data to the memory for storage.

41. The debugging proxy of claim 33, wherein the first connector and the second connector comprise JDI (Java debug interface) connectors.

42. A debugging system comprising:

a debugging component;

a first proxy component coupled with the debugging component;

a memory coupled with the first proxy component for storage of data regarding events of a target computing system, and

a link with a second proxy component, the first proxy component to receive event notifications from the target computing system and data regarding events of the target computing system via the second proxy component.

43. The debugging system of claim 42, wherein the first proxy component is to search the memory upon receiving a request for data from the debugging component.

44. The debugging system of claim 43, wherein the first proxy component directs the requested data to the debugging component if the requested data is present in the memory and directs the request for data to the target system if the requested data is not present in the memory.

45. The debugging system of claim 42, further comprising a user interface for making the request for data.

46. The debugging system of claim 42, wherein the debugging system is a Java platform debugger architecture (JPDA) system.

47. The debugging system of claim 42, wherein the first proxy component communicates with the second proxy component communicate using Java debug wire protocol (JDWP).

48. A machine-readable medium having stored thereon data representing sequences of instructions that, when executed by a processor, cause the processor to perform operations comprising:

receiving notification of an event regarding a target computing system;

receiving data regarding the event;

storing the data regarding the event;

receiving a request for data regarding the event from a debugging component; and

determining whether the requested data is stored.

49. The medium of claim 48, further comprising instructions that, when executed by a processor, cause the processor to perform operations comprising:

if the data is stored, sending a reply containing the stored data to the debugging component; and

if the data is not stored, sending the data request to the target computing system.

50. The medium of claim 49, wherein receiving notification of the event includes receiving the notification at a proxy for the debugging component.

51. The medium of claim 50, wherein sending the data request to the target computing system includes providing the data request to a proxy for the target computing system.

52. The medium of claim 48, wherein storing the data regarding the event comprises storing the data in a cache memory.