Server throttled client debugging

Systems and methods of debugging client applications may provide for detecting a runtime error in a first version of a client application, and obtaining a second version of the client application server in response to the runtime error. The second version of the client application may be used to conduct a diagnosis of the runtime error.

BACKGROUND

1. Technical Field

Embodiments of the present invention generally relate to application debugging. More particularly, embodiments relate to client-side application debugging.

In modern web-based applications, the performance of the application may be directly related to the size and amount of the files that are served to the client. Efforts to reduce the amount, and therefore size, of client-side code can be at odds with efforts to include a multitude of meaningful logging, debugging and tracing functionality. A common practice may be to remove unnecessary white-space at build time and compress the source files before serving them to the client. This approach could still include, however, all of the trace, debug and log statements, which may not always be needed.

BRIEF SUMMARY

Embodiments may provide for a computer program product including a computer readable storage medium and computer usable code stored on the computer readable storage medium. If executed by a processor, the computer usable code causes a computer to detect a runtime error in a first version of a client application and obtain a second version of the client application from a server in response to the error. The computer usable code, if executed, can also cause a computer to use the second version of the client application to conduct a diagnosis of the error.

Embodiments may also provide for a method of debugging a client application in which a runtime error is detected in a first version of the client application. A second version of the client application can be obtained in response to the error, wherein the second version of the client application is used to conduct a diagnosis of the error.

In addition, embodiments can include a method of debugging a client application in which a runtime error is detected in a first version of a client application. A server notification may be transmitted in response to the runtime error, wherein the server notification includes one or more details of the error. A second version of the client application can be received, wherein the second version of the client application has a debug capability that corresponds to a level of the error. The method may also provide for installing the second version of the client application and using the second version of the client application to conduct a diagnosis of the error.

Other embodiments can include a computer program product having a computer readable storage medium and computer usable code stored on the computer readable storage medium. If executed by a processor, the computer usable code can cause a computer to receive a server notification, wherein the server notification is to include one or more details of a runtime error associated with a first version of the client application. A second version of the client application may be selected based on the one or more details of the error and the second version of the client application can be transmitted to a client.

DETAILED DESCRIPTION

Referring now toFIG. 1, a networking architecture10is shown in which a server12uses either a production version14of an application or one or more debug versions16of an application to communicate with client-side user equipment (UE)18. In the illustrated example, the UE18may include a personal computer (PC), notebook computer, personal digital assistant (PDA), wireless smartphone, or other device having access to the server12, via a network20. The UE18connection to the network20may include a wireless data connection (e.g., IEEE 802.11, 1999 Edition, LAN/MAN Wireless LANS (WiFi), IEEE 802.16-2004, LAN/MAN Broadband Wireless LANS (WiMAX), etc.), a cellular telephone connection (e.g., W-CDMA (UMTS), CDMA2000 (IS-856/IS-2000), etc.), a wired data connection (e.g., RS-232 (Electronic Industries Alliance/EIA), Ethernet (e.g., IEEE 802.3-2005, LAN/MAN CSMA/CD Access Method), power line communication (e.g., X10, IEEE P1675), USB (e.g., Universal Serial Bus 2.0 Specification)), etc., depending upon the circumstances. The UE18and server12could be located in the same physical location or in different locations.

In addition, the network20can include any suitable combination of servers, access points, routers, base stations, mobile switching centers, public switching telephone network (PSTN) components, etc., to facilitate communication between the UE18and the server12. The server12may include distributed and/or redundant web-based servers that are able to respond to web page requests for content. Thus, the server12can have stored thereon hypertext markup language (HTML) and other markup language-encoded content, as well as databases and applications such as Java and other applications. The server12could also be part of a cloud computing environment in which resources are shared across platforms in a complex fashion.

The versions14,16of the application, which might enable a wide variety of activities including, but not limited to, electronic commerce (e-commerce), multimedia, gaming, business-to-business (B2B) activities, etc., can include both server-side logic and client-side logic. Generally, the UE18initially loads/installs and uses client-side logic of the production version14during normal operation. The production version14of the application may include minimal debugging capability in order to minimize the size of the client-side code to be distributed and/or installed at the UE18. Thus, the production version14of the application might be equipped to handle only trivial errors and exceptions such as an HTTP code 404 for a piece of content not being found. The debug version16of the application, on the other hand, may have more robust debug capability than the production14, wherein the debug version16can be provided to the UE18on an as-needed basis. In one example, the client-side logic of the debug version16may be developed with debug statements tagged at various error levels to obtain a plurality of “sub-versions” of the debug version16, wherein each sub-version is equipped to handle a certain severity, level and/or type of client-side error. The debug statements might be stripped out programmatically to create the production version14.

FIG. 2shows one example of normal operation between the server12and the UE18in which requests22are issued by the UE (Clients1and2)18to the production version14of the application running on server12. The illustrated production version14of the application generates responses24based on the requests. As already noted, the requests22and responses24might relate to e-commerce, multimedia, gaming, B2B, and other activities, and the client-side logic may be relatively small due to a lack of enhanced of debugging capability.

Turning now toFIG. 3, a sequence is shown in which a runtime error is encountered at the UE18. In the illustrated example, an error notification (e.g., runtime error server notification)26is transmitted to the production version14of the server-side application logic at stage28, wherein the notification can include one or more details of the runtime error encountered at the UE18. In particular, the details could include an identification of the error itself as well as an identification of the state of the UE18at the time of the error. At stage30, the server12may select a debug version16(e.g., from a plurality of debug versions) based on the details of the runtime error, and transmit the client-side logic32of the selected debug version16to the UE18. Upon receipt, the UE18may install the client-side logic32of the selected debug version16of the application, and begin functioning and communicating using the client-side logic32of the debug version16at stage34.

In particular, the client-side logic32might prompt the user of the UE18to re-try the action that induced the runtime error and/or to take other actions with the software. The client-side logic32can collect and report the debug information39associated with these actions at stage40. The decision to report the debug information39can be based on a wide variety of factors. For example, the debug information39might be transmitted back to the server12if the user navigates away from the client application (e.g., an application departure condition is met), or if a debug threshold is reached. Examples of debug thresholds include, but are not limited to, durations of time and error thresholds such as a number of errors or a level of severity.

The debug information39may be reported back to the server12via one or more request36and response38interactions, wherein the reported debug information39could be used to select and load other versions of the client-side debug application and/or to conduct a more detailed analysis of the results. The selection and loading of additional debug versions16can provide for a throttling of code instrumentation that enables a gradual increase in the size of the client-side code. Such an approach could mitigate performance degradations associated with collecting and reporting debug information39. Once the debug version16of the application determines that enough information has been gathered, the client-side logic of the production version14may be automatically resent to the UE18, enabling it to revert to its optimal size and performance.

FIGS. 4A and 4Bshow methods42and44of client-side and server-side application debugging, respectively. The methods42and44could be implemented in executable software as a set of logic instructions stored in a machine- or computer-readable medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), flash memory, etc., as fixed-functionality hardware using circuit technology such as application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof.

Processing block46provides for detecting a runtime error in a first version of a client application. In one example, the first version is a production version of the application, wherein the runtime error is detected by client-side logic that has a high level of performance and might not be structured to handle the runtime error. A second version of the application may be obtained from a server at block48in response to the runtime error. For example, a server notification of the error might be issued, wherein illustrated block50provides for receiving the notification at the server. In the illustrated example, the server notification includes one or more details of the runtime error such as an identification of the error and an indication of the state of the client device at the time the error occurred. A second version of the client application can be selected from a plurality of debug versions at block52, wherein the second version may have a debug capability that corresponds to the level of the runtime error.

Illustrated block54provides for transmitting the selected second version of the client application to the client. Once the second version of the client application has been obtained, the client may use the second version to conduct a diagnosis of the runtime error at block56. As already discussed, the diagnosis might involve prompting for one or more actions including a re-try of the action that induced the runtime error, collecting debug information associated with the one or more actions, and transmitting the debug information to the server. Reporting of the debug information can be based on a number of factors such as debug thresholds and/or application departure conditions.