U.S. patent application number 11/221667 was filed with the patent office on 2007-03-08 for remote debugging proxy.
Invention is credited to Richard Birenheide, Eckart Langhuth, Matthias Thorsten Metzler.
Application Number | 20070055957 11/221667 |
Document ID | / |
Family ID | 37831340 |
Filed Date | 2007-03-08 |
United States Patent
Application |
20070055957 |
Kind Code |
A1 |
Birenheide; Richard ; et
al. |
March 8, 2007 |
Remote debugging proxy
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.
Inventors: |
Birenheide; Richard;
(Neckargemund, DE) ; Langhuth; Eckart; (Wiesloch,
DE) ; Metzler; Matthias Thorsten; (Forst,
DE) |
Correspondence
Address: |
BLAKELY SOKOLOFF TAYLOR & ZAFMAN
12400 WILSHIRE BOULEVARD
SEVENTH FLOOR
LOS ANGELES
CA
90025-1030
US
|
Family ID: |
37831340 |
Appl. No.: |
11/221667 |
Filed: |
September 7, 2005 |
Current U.S.
Class: |
717/124 ;
714/E11.207 |
Current CPC
Class: |
G06F 11/362
20130101 |
Class at
Publication: |
717/124 |
International
Class: |
G06F 9/44 20060101
G06F009/44 |
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.
Description
TECHNICAL FIELD
[0001] 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
[0002] 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.
[0003] 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.
[0004] 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
[0005] A system and method for a remote debugging proxy are
described.
[0006] 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.
[0007] 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
[0008] 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.
[0009] FIG. 1 is an illustration of an embodiment of a remote proxy
debugging system;
[0010] FIG. 2 is an illustration of an embodiment of a local proxy
engine;
[0011] FIG. 3 is an illustration of an embodiment of a remote proxy
engine;
[0012] FIG. 4 is an illustration of an embodiment of an information
collector for a remote proxy engine;
[0013] FIG. 5 is an illustration of an embodiment of a JDI
connector that may be utilized in a proxy engine; and
[0014] FIG. 6 is a flow chart to illustrate an embodiment of remote
debugging of an application by proxy.
DETAILED DESCRIPTION
[0015] Embodiments of the invention are generally directed to a
system and method for a remote debug proxy.
[0016] 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.
[0017] 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.
[0018] 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.
[0019] 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:
[0020] (a) Java Virtual Machine Debug Interface (JVMDI)--The
interface defining the debugging services that a virtual machine
provides.
[0021] (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.
[0022] (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.
[0023] 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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] 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.
[0036] 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.
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
* * * * *