US20030131282A1 - System and method of error retention for threaded software - Google Patents

System and method of error retention for threaded software Download PDF

Info

Publication number
US20030131282A1
US20030131282A1 US10/042,503 US4250302A US2003131282A1 US 20030131282 A1 US20030131282 A1 US 20030131282A1 US 4250302 A US4250302 A US 4250302A US 2003131282 A1 US2003131282 A1 US 2003131282A1
Authority
US
United States
Prior art keywords
application
log
thread
logger
computer readable
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US10/042,503
Other versions
US7017077B2 (en
Inventor
Daniel Lowen
Clifford Hayden
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Priority to US10/042,503 priority Critical patent/US7017077B2/en
Assigned to INTERNATIONAL BUSINESS MACHINES CORPORATION reassignment INTERNATIONAL BUSINESS MACHINES CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: HAYDEN, CLIFFORD O., LOWEN, DANIEL S.
Publication of US20030131282A1 publication Critical patent/US20030131282A1/en
Application granted granted Critical
Publication of US7017077B2 publication Critical patent/US7017077B2/en
Adjusted expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0787Storage of error reports, e.g. persistent data storage, storage using memory protection
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0715Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a system implementing multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766Error or fault reporting or storing
    • G06F11/0778Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments for testing or debugging software

Definitions

  • the invention relates to computer software. More specifically, the invention relates to increased error specification using a method of error retention for threaded production software.
  • One aspect of the invention provides a method for error detection of multi-threaded application software.
  • the method may include providing application threads with access to a logger that collects a thread's log statements in memory and can persist all of those statements in case of an error in the production environment.
  • the method may also include detecting a death of an application thread by the logger and deleting the application thread's log statements after thread death detection.
  • Another aspect of the invention provides a system for error detection of multi-threaded software.
  • the system comprising a means for executing an application which uses a logger that collects log statements, means for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory and means for allowing the collected log statement to be persisted in case of an error in a production environment.
  • the system may also include means for detecting a death of an application thread by the logger and means for deleting the application thread's log statements after thread death detection.
  • Another aspect of the invention provides a computer readable medium storing a computer program.
  • the computer readable medium comprising computer readable code for executing an application which uses a logger that collects log statements, computer readable code for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory, and computer readable code for allowing the collected log statement to be persisted in case of an error in a production environment.
  • the computer readable medium may include computer readable code for detecting a death of an application thread by the logger, and computer readable code for deleting the application thread's log statements after thread death detection.
  • FIG. 1 is a block diagram illustrating one embodiment for a method of operation of an in-memory logger in accordance with the present invention
  • FIG. 2 is a flowchart representation of one embodiment for an application thread interaction with the in-memory logger of FIG. 1, in accordance with the present invention
  • FIG. 3 is a flowchart representation of a preferred embodiment for an instance method used by the application thread of FIG. 2, in accordance with the present invention
  • FIG. 4 is a flowchart representation of a preferred embodiment for a constructor of a logger object as associated with the instance method of FIG. 3, in accordance with the present invention
  • FIG. 5 is a flowchart representation of a preferred embodiment for a configuration monitor as associated with the logger object of FIG. 4, in accordance with the present invention
  • FIG. 6 is a flowchart representation of a preferred embodiment for a thread death monitor as associated with the logger object of FIG. 4, in accordance with the present invention
  • FIG. 7 is a flowchart representation of a preferred embodiment for a log message thread, as associated with the logger object of FIG. 4, in accordance with the present invention.
  • FIG. 8 is a flowchart representation of a preferred embodiment for the destructor of the logger object of FIG. 4, in accordance with the present invention.
  • FIG. 9 is a flowchart representation of a preferred embodiment for a log message thread, as associated with the logger object of FIG. 4, in accordance with the present invention.
  • FIG. 10 is a flowchart representation of a preferred embodiment for a write log method, used by the application thread of FIG. 2, in accordance with the present invention.
  • FIG. 1 illustrates one embodiment for a method of operation of an in-memory logger 100 in accordance with the present invention.
  • the illustrated embodiment of the invention demonstrates that a logger 120 may reside on an operating system 150 , and an additional embodiment may provide the operating system 150 to reside on a Web Application Server 140 .
  • the logger 120 may respond to a request from threads of execution operating as part of a software application 110 .
  • One embodiment of the invention may depict the interacting software application 110 as a Web application.
  • FIG. 1 illustrates an embodiment of the invention where the logger 120 may be integrated into the base class of an application framework 130 thus easing the applications' 110 access to the logger.
  • FIG. 2 illustrates, as a flowchart representation, one embodiment of how an application thread may interact with an embodiment of an in-memory logger (logger) compatible with the system of FIG. 1.
  • An application production software
  • the application thread may activate a thread 205 .
  • the application thread may obtain an instance of the logger 210 .
  • the logger may be a Singleton design pattern object.
  • the logger can then receive data (log statements) from the application thread 215 , 220 .
  • the application thread can indicate to the logger the log statement's retention level 215 , 200 .
  • the application thread can call the logger's write log method to direct the logger to persist all log statements the logger received from the application thread 225 .
  • One embodiment of the invention may place each log statement into a log message queue, store the log statements in memory, and may write the log statements to a persistence mechanism as is known in the art.
  • the logger will detect the thread's death and discard the log statements stored in memory 230 .
  • FIG. 3 Illustrated in FIG. 3, is an embodiment of the logger as a Singleton design pattern object 300 .
  • the logger's static instance method may inquire a static variable indicating whether an instance of the logger has already been constructed 320 . If the logger has not yet been constructed then the instance method will construct a new logger object 330 . Upon exit of the instance method, the single instance of the logger object is returned 340 .
  • FIG. 4 illustrates a flowchart representation of a logger object's constructor 400 associated with the logger's instance method 300 of FIG. 3.
  • the logger object constructor 400 may begin by instantiating an object to inventory the threads 415 .
  • the logger object constructor 400 may instantiate an object to manage any accumulated application threads' log statements 425 .
  • a thread death monitor may be activated 435 to monitor application threads' operational status.
  • the minimum retention level of qualifying log statements and a predetermined waiting period for monitoring function control is retrieved 445 by the logger object constructor 400 for use with the activation of a configuration monitor 455 .
  • the logger object constructor 400 may continue by instantiating a log message queue 465 and complete operation by activating a log message thread to monitor the log message queue 475 .
  • the configuration monitor 500 may suspend operation 510 for a duration of time (waiting period) defined in the logger object constructor 400 of FIG. 4. After the waiting period has lapsed, the configuration monitor 500 looks for a termination indicator. If a termination indicator is found then the configuration monitor may exit 540 . If a termination indicator is not found then the configuration monitor may re-obtain the minimum retention level of qualifying log statements and a predetermined waiting period for monitoring function and configuration data 530 and may again suspend operation 510 .
  • a termination indicator is found then the configuration monitor may exit 540 . If a termination indicator is not found then the configuration monitor may re-obtain the minimum retention level of qualifying log statements and a predetermined waiting period for monitoring function and configuration data 530 and may again suspend operation 510 .
  • FIG. 6 One embodiment of the thread death monitor associated with the logger object constructor 400 of FIG. 4 is illustrated as a flowchart in FIG. 6.
  • the thread death monitor 600 suspends operation 610 for the duration of time defined in the logger object constructor 400 of FIG. 4 or redefined in the configuration monitor 500 of FIG. 5.
  • the thread death monitor 600 looks for a termination indicator 615 . If a termination indicator is found then the configuration monitor may exit 640 . Otherwise, for each application thread that requested an instance of the logger 620 , the thread death monitor 600 obtains the application thread's state of operation 625 .
  • the thread death monitor 600 may remove the application thread's log from the log manager 630 and may remove the application thread from the thread manager 635 . After processing each application thread entry in the thread manager 620 , the thread death monitor 600 may again suspend operation 610 .
  • FIG. 7 illustrates, as a flowchart, the operations of the logger's log method 700 that is exposed to application threads to allow application threads to pass a log statement to the logger.
  • Activation of the log method 700 occurs when an application thread submits a log statement to the logger along with the log statement's retention level 705 .
  • the log method 700 may then obtain a time stamp 715 .
  • the log method 700 may continue and obtain the requesting application thread's identification 720 .
  • the application thread's identification data is compared to thread identification data in the thread manager 725 .
  • the log method 730 may check if application thread's identification is unique. If the application thread's identification is not unique then the log method 700 may assign unique thread identification 735 to the application thread. Once the unique thread identification has been assigned, the application thread's unique thread identification may be added to the thread manager 740 .
  • the log method 700 may combine the timestamp, the application thread's identification, and log statement as a new log message 745 .
  • the log method 700 may then write the new log message along with its retention level to the log message queue 750 , which ends the log method 700 operation.
  • FIG. 8 illustrates a flowchart representation of a logger object destructor 800 .
  • the logger object destructor 800 may begin by setting a termination indicator to true 820 which may cause the configuration monitor 500 and the thread death monitor 600 to terminate.
  • the logger object destructor may then use the log method to pass a log statement to background log message thread indicating that it too should terminate 830 which ends the logger object destructor 800 operation.
  • FIG. 9 illustrates one embodiment of a log message thread 900 associated with the logger object constructor 400 of FIG. 4.
  • the log message thread processes messages placed on the logger's log message queue. Subsequent to activation 910 , the log message thread may repeatedly obtain and process messages arriving on the log message queue 920 . For each arriving message, the log message thread may dequeue the log message and its retention level from the log message queue 920 . If the retention level has been set to equal terminate 930 , the log message thread 900 may terminate 970 . Otherwise, the error message may be added to the application thread's log in the log manager 940 . If the log message's retention level is greater then or equal to the minimum retention level defined in the logger object constructor 400 of FIG.
  • the log message thread may write the log message to the persistence mechanism 960 .
  • the log message thread 900 may return to obtain process another log message from the log message queue 920 . This process may continue until the retention level has been set to equal terminate 930 , and the log message thread 900 terminates 970 .
  • the logger's write log method 984 illustrated in FIG. 10 as a flowchart and associated with FIG. 1, writes the requesting application thread's log statements to the persistence mechanism.
  • the method may begin 984 by obtaining the requesting application thread's identification 988 .
  • the write log method 984 may retrieve the requesting application thread's log statements from the log manager 990 .
  • the write log method 984 may then be written to the retrieved log statements to the persistence mechanism 994 , which then ends the write log method 984 operation.

Abstract

The invention provides a method for error detection of multi-threaded software. The method comprises executing an application which uses a logger that collects log statements, collecting at least one log statement from at least one application thread and storing the at least one log statement in memory, and allowing the collected log statement to be persisted in case of an error in a production environment.

Description

    FIELD OF THE INVENTION
  • In general, the invention relates to computer software. More specifically, the invention relates to increased error specification using a method of error retention for threaded production software. [0001]
  • BACKGROUND OF THE INVENTION
  • Defects in production application software that process a large volume of requests via frequently created short-lived threads, such as applications implemented on modern Web application servers, are notoriously difficult to correct. [0002]
  • Development teams that build application software typically implement a configurable logging facility that produces log statements that are persisted to a file, or to a database. These logging facilities usually allow various levels of logging. At debug levels, the typical logging facility produces a detailed log. At production levels, typically only a health check or detected error conditions are logged. [0003]
  • The statements captured in a debug level log are invaluable when diagnosing the cause of unexpected errors especially those caused by defects in the software itself. However, if production software were to log debug level statements, the resulting performance degradation caused by persisting the log would be prohibitive. As production software executes more threads, the multiple threads would exacerbate the performance degradation. [0004]
  • Thus, there is a significant need for a system and method for improving retention of error information (error logging) that overcomes the above disadvantages and shortcomings, as well as other disadvantages. [0005]
  • BRIEF SUMMARY OF THE INVENTION
  • One aspect of the invention provides a method for error detection of multi-threaded application software. The method may include providing application threads with access to a logger that collects a thread's log statements in memory and can persist all of those statements in case of an error in the production environment. The method may also include detecting a death of an application thread by the logger and deleting the application thread's log statements after thread death detection. [0006]
  • Another aspect of the invention provides a system for error detection of multi-threaded software. The system comprising a means for executing an application which uses a logger that collects log statements, means for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory and means for allowing the collected log statement to be persisted in case of an error in a production environment. The system may also include means for detecting a death of an application thread by the logger and means for deleting the application thread's log statements after thread death detection. [0007]
  • Another aspect of the invention provides a computer readable medium storing a computer program. The computer readable medium comprising computer readable code for executing an application which uses a logger that collects log statements, computer readable code for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory, and computer readable code for allowing the collected log statement to be persisted in case of an error in a production environment. The computer readable medium may include computer readable code for detecting a death of an application thread by the logger, and computer readable code for deleting the application thread's log statements after thread death detection. [0008]
  • The foregoing and other features and advantages of the invention will become further apparent from the following detailed description of the presently preferred embodiment, read in conjunction with the accompanying drawings. The detailed description and drawings are merely illustrative of the invention rather than limiting, the scope of the invention being defined by the appended claims and equivalents thereof.[0009]
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 is a block diagram illustrating one embodiment for a method of operation of an in-memory logger in accordance with the present invention; [0010]
  • FIG. 2 is a flowchart representation of one embodiment for an application thread interaction with the in-memory logger of FIG. 1, in accordance with the present invention; [0011]
  • FIG. 3 is a flowchart representation of a preferred embodiment for an instance method used by the application thread of FIG. 2, in accordance with the present invention; [0012]
  • FIG. 4 is a flowchart representation of a preferred embodiment for a constructor of a logger object as associated with the instance method of FIG. 3, in accordance with the present invention; [0013]
  • FIG. 5 is a flowchart representation of a preferred embodiment for a configuration monitor as associated with the logger object of FIG. 4, in accordance with the present invention; [0014]
  • FIG. 6 is a flowchart representation of a preferred embodiment for a thread death monitor as associated with the logger object of FIG. 4, in accordance with the present invention; [0015]
  • FIG. 7 is a flowchart representation of a preferred embodiment for a log message thread, as associated with the logger object of FIG. 4, in accordance with the present invention; [0016]
  • FIG. 8 is a flowchart representation of a preferred embodiment for the destructor of the logger object of FIG. 4, in accordance with the present invention; [0017]
  • FIG. 9 is a flowchart representation of a preferred embodiment for a log message thread, as associated with the logger object of FIG. 4, in accordance with the present invention; and [0018]
  • FIG. 10 is a flowchart representation of a preferred embodiment for a write log method, used by the application thread of FIG. 2, in accordance with the present invention.[0019]
  • DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS
  • FIG. 1 illustrates one embodiment for a method of operation of an in-[0020] memory logger 100 in accordance with the present invention. The illustrated embodiment of the invention demonstrates that a logger 120 may reside on an operating system 150, and an additional embodiment may provide the operating system 150 to reside on a Web Application Server 140. The logger 120 may respond to a request from threads of execution operating as part of a software application 110. One embodiment of the invention may depict the interacting software application 110 as a Web application. Additionally, FIG. 1 illustrates an embodiment of the invention where the logger 120 may be integrated into the base class of an application framework 130 thus easing the applications' 110 access to the logger.
  • FIG. 2 illustrates, as a flowchart representation, one embodiment of how an application thread may interact with an embodiment of an in-memory logger (logger) compatible with the system of FIG. 1. An application (production software) may activate a [0021] thread 205. The application thread may obtain an instance of the logger 210. In one embodiment of the invention the logger may be a Singleton design pattern object. The logger can then receive data (log statements) from the application thread 215, 220. For one embodiment of the invention, the application thread can indicate to the logger the log statement's retention level 215, 200. If the application thread detects an error, the application thread can call the logger's write log method to direct the logger to persist all log statements the logger received from the application thread 225. One embodiment of the invention may place each log statement into a log message queue, store the log statements in memory, and may write the log statements to a persistence mechanism as is known in the art. After the production software's application thread termination, the logger will detect the thread's death and discard the log statements stored in memory 230.
  • Illustrated in FIG. 3, is an embodiment of the logger as a Singleton design pattern object [0022] 300. When an instance of the logger is requested 310, the logger's static instance method may inquire a static variable indicating whether an instance of the logger has already been constructed 320. If the logger has not yet been constructed then the instance method will construct a new logger object 330. Upon exit of the instance method, the single instance of the logger object is returned 340.
  • FIG. 4 illustrates a flowchart representation of a logger object's [0023] constructor 400 associated with the logger's instance method 300 of FIG. 3. When activated 405, the logger object constructor 400 may begin by instantiating an object to inventory the threads 415. In addition, the logger object constructor 400 may instantiate an object to manage any accumulated application threads' log statements 425. A thread death monitor may be activated 435 to monitor application threads' operational status. The minimum retention level of qualifying log statements and a predetermined waiting period for monitoring function control is retrieved 445 by the logger object constructor 400 for use with the activation of a configuration monitor 455. The logger object constructor 400 may continue by instantiating a log message queue 465 and complete operation by activating a log message thread to monitor the log message queue 475.
  • One embodiment of the configuration monitor associated with the [0024] logger object constructor 400 of FIG. 4 is illustrated as a flowchart in FIG. 5. After its activation 505, the configuration monitor 500 may suspend operation 510 for a duration of time (waiting period) defined in the logger object constructor 400 of FIG. 4. After the waiting period has lapsed, the configuration monitor 500 looks for a termination indicator. If a termination indicator is found then the configuration monitor may exit 540. If a termination indicator is not found then the configuration monitor may re-obtain the minimum retention level of qualifying log statements and a predetermined waiting period for monitoring function and configuration data 530 and may again suspend operation 510.
  • One embodiment of the thread death monitor associated with the [0025] logger object constructor 400 of FIG. 4 is illustrated as a flowchart in FIG. 6. After its activation 605, the thread death monitor 600 suspends operation 610 for the duration of time defined in the logger object constructor 400 of FIG. 4 or redefined in the configuration monitor 500 of FIG. 5. After the waiting period has lapsed, the thread death monitor 600 looks for a termination indicator 615. If a termination indicator is found then the configuration monitor may exit 640. Otherwise, for each application thread that requested an instance of the logger 620, the thread death monitor 600 obtains the application thread's state of operation 625. If an application thread is found to be inactive, the thread death monitor 600 may remove the application thread's log from the log manager 630 and may remove the application thread from the thread manager 635. After processing each application thread entry in the thread manager 620, the thread death monitor 600 may again suspend operation 610.
  • FIG. 7 illustrates, as a flowchart, the operations of the logger's [0026] log method 700 that is exposed to application threads to allow application threads to pass a log statement to the logger. Activation of the log method 700 occurs when an application thread submits a log statement to the logger along with the log statement's retention level 705. The log method 700 may then obtain a time stamp 715. The log method 700 may continue and obtain the requesting application thread's identification 720. The application thread's identification data is compared to thread identification data in the thread manager 725.
  • If the application thread's identification is not found in the thread manager, the [0027] log method 730 may check if application thread's identification is unique. If the application thread's identification is not unique then the log method 700 may assign unique thread identification 735 to the application thread. Once the unique thread identification has been assigned, the application thread's unique thread identification may be added to the thread manager 740.
  • Once the application thread's identification is in the thread manager, the [0028] log method 700 may combine the timestamp, the application thread's identification, and log statement as a new log message 745. The log method 700 may then write the new log message along with its retention level to the log message queue 750, which ends the log method 700 operation.
  • FIG. 8 illustrates a flowchart representation of a [0029] logger object destructor 800. When activated 810, the logger object destructor 800 may begin by setting a termination indicator to true 820 which may cause the configuration monitor 500 and the thread death monitor 600 to terminate. The logger object destructor may then use the log method to pass a log statement to background log message thread indicating that it too should terminate 830 which ends the logger object destructor 800 operation.
  • FIG. 9 illustrates one embodiment of a log message thread [0030] 900 associated with the logger object constructor 400 of FIG. 4. The log message thread processes messages placed on the logger's log message queue. Subsequent to activation 910, the log message thread may repeatedly obtain and process messages arriving on the log message queue 920. For each arriving message, the log message thread may dequeue the log message and its retention level from the log message queue 920. If the retention level has been set to equal terminate 930, the log message thread 900 may terminate 970. Otherwise, the error message may be added to the application thread's log in the log manager 940. If the log message's retention level is greater then or equal to the minimum retention level defined in the logger object constructor 400 of FIG. 4 or redefined in the configuration monitor 500 of FIG. 5, the log message thread may write the log message to the persistence mechanism 960. After the message has been written 960, or if the retention level is less then the minimum retention level 950, the log message thread 900 may return to obtain process another log message from the log message queue 920. This process may continue until the retention level has been set to equal terminate 930, and the log message thread 900 terminates 970.
  • The logger's [0031] write log method 984, illustrated in FIG. 10 as a flowchart and associated with FIG. 1, writes the requesting application thread's log statements to the persistence mechanism. The method may begin 984 by obtaining the requesting application thread's identification 988. The write log method 984 may retrieve the requesting application thread's log statements from the log manager 990. The write log method 984 may then be written to the retrieved log statements to the persistence mechanism 994, which then ends the write log method 984 operation.
  • The above-described methods and implementation of error retention for threaded production software are example methods and implementations. These methods and implementations illustrate one possible approach for error retention for threaded production software. The actual implementation may vary from the method discussed. Moreover, various other improvements and modifications to this invention may occur to those skilled in the art, and those improvements and modifications will fall within the scope of this invention as set forth below. [0032]
  • While the embodiments of the invention disclosed herein are presently considered to be preferred, various changes and modifications can be made without departing from the spirit and scope of the invention. The scope of the invention is indicated in the appended claims, and all changes that come within the meaning and range of equivalents are intended to be embraced therein. [0033]

Claims (18)

We claim
1. A method of error retention for multi-threaded software, comprising:
executing an application which uses a logger that collects log statements;
collecting at least one log statement from at least one application thread and storing the at least one log statement in memory; and
allowing the collected log statement to be persisted in case of an error in a production environment.
2. The method of claim 1 wherein the application and logger are implemented on a web application server.
3. The method of claim 1 wherein the executing application is run in a development environment.
4. The method of claim 1 wherein the executing application is run in a test environment.
5. The method of claim 1 wherein the logger is built into a base class of an object oriented application framework.
6. The method of claim 1 wherein the production application is an Internet accessible application.
7. The method of claim 1 wherein the method can be implemented using background threads.
8. The method of claim 1 further comprising:
detecting a death of an application thread by the logger; and
deleting the application thread's log statements after thread death detection.
9. A system of error retention for multi-threaded software, comprising:
means for executing an application which uses a logger that collects log statements;
means for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory; and
means for allowing the collected log statement to be persisted in case of an error in a production environment.
10. The system of claim 9 further comprising:
means for detecting a death of an application thread by the logger; and
means for deleting the application thread's log statements after thread death detection.
11. A computer readable medium storing a computer program comprising:
computer readable code for executing an application which uses a logger that collects log statements;
computer readable code for collecting at least one log statement from at least one application thread and storing the at least one log statement in memory; and
computer readable code for allowing the collected log statement to be persisted in case of an error in a production environment.
12. The computer readable medium of claim 11 wherein the application and logger are implemented on a web application server.
13. The computer readable medium of claim 11 wherein the executing application is run in a development environment.
14. The computer readable medium of claim 11 wherein the executing application is run in a test environment.
15. The computer readable medium of claim 11 wherein the logger is built into a base class of an object oriented application framework.
16. The computer readable medium of claim 11 wherein the production application is an Internet accessible application.
17. The computer readable medium of claim 11 wherein the method can be implemented using background threads.
18. The computer readable medium of claim 11 further comprising:
computer readable code for detecting a death of an application thread by the logger; and
computer readable code for deleting the application thread's log statements after thread death detection.
US10/042,503 2002-01-09 2002-01-09 System and method of error retention for threaded software Expired - Fee Related US7017077B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/042,503 US7017077B2 (en) 2002-01-09 2002-01-09 System and method of error retention for threaded software

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/042,503 US7017077B2 (en) 2002-01-09 2002-01-09 System and method of error retention for threaded software

Publications (2)

Publication Number Publication Date
US20030131282A1 true US20030131282A1 (en) 2003-07-10
US7017077B2 US7017077B2 (en) 2006-03-21

Family

ID=21922281

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/042,503 Expired - Fee Related US7017077B2 (en) 2002-01-09 2002-01-09 System and method of error retention for threaded software

Country Status (1)

Country Link
US (1) US7017077B2 (en)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050028145A1 (en) * 2003-07-31 2005-02-03 Sun Microsystems, Inc. Flexible error trace mechanism
US20050154938A1 (en) * 2003-12-19 2005-07-14 International Business Machines Corp. Autonomic method to resume multi-threaded preload imaging process
EP1662396A2 (en) * 2004-11-26 2006-05-31 Fujitsu Limited Hardware error control method in an instruction control apparatus having an instruction processing suspension unit
WO2012087402A1 (en) * 2010-12-23 2012-06-28 Intel Corporation Method and system for detecting abnormal interleavings in concurrent programs
CN102842007A (en) * 2012-07-16 2012-12-26 腾讯科技(深圳)有限公司 Access control method and system of mobile terminal application program
US20160098342A1 (en) * 2014-10-05 2016-04-07 YScope Inc. Systems and processes for computer log analysis
US20180373581A1 (en) * 2017-06-23 2018-12-27 Microsoft Technology Licensing, Llc System and methods for optimal error detection in programmatic environments
US11449411B2 (en) * 2020-06-02 2022-09-20 Red Hat, Inc. Application-specific log routing

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7734961B2 (en) * 2007-05-01 2010-06-08 International Business Machines Corporation Distributed logging apparatus system and method
US8190260B2 (en) * 2009-03-24 2012-05-29 Medtronic, Inc. Lead retention and sealing device
US20100249871A1 (en) * 2009-03-24 2010-09-30 Medtronic, Inc. Full Visibility Lead Retention
US8032221B2 (en) * 2009-03-24 2011-10-04 Medtronic, Inc. Sealing setscrew
US20110083123A1 (en) * 2009-10-05 2011-04-07 Microsoft Corporation Automatically localizing root error through log analysis
US10114830B2 (en) 2015-09-28 2018-10-30 Oracle International Corporation Lazy logger wrappers
US10346287B1 (en) 2018-06-06 2019-07-09 The United States Of America, As Represented By The Secretary Of The Navy Detection of degenerate software forms in object oriented code

Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884022A (en) * 1996-06-03 1999-03-16 Sun Microsystems, Inc. Method and apparatus for controlling server activation in a multi-threaded environment
US5913041A (en) * 1996-12-09 1999-06-15 Hewlett-Packard Company System for determining data transfer rates in accordance with log information relates to history of data transfer activities that independently stored in content servers
US6012066A (en) * 1997-10-01 2000-01-04 Vallon, Inc. Computerized work flow system
US6044398A (en) * 1997-11-21 2000-03-28 International Business Machines Corporation Virtual dynamic browsing system and method for automated web server and testing
US6138149A (en) * 1997-06-05 2000-10-24 Sony Corporation System for tracking information copied from a web page and sent via electronic mail
US6175838B1 (en) * 1998-04-29 2001-01-16 Ncr Corporation Method and apparatus for forming page map to present internet data meaningful to management and business operation
US6192382B1 (en) * 1997-09-24 2001-02-20 Mediaone Group, Inc. Method and system for web site construction using HTML fragment caching
US20020034134A1 (en) * 2000-09-19 2002-03-21 Minoru Hirashima Disk reading apparatus
US6389426B1 (en) * 1999-02-09 2002-05-14 Worldcom, Inc. Central trouble ticket database and system and method for managing same to facilitate ticketing, trending, and tracking processes
US6457142B1 (en) * 1999-10-29 2002-09-24 Lucent Technologies Inc. Method and apparatus for target application program supervision
US6539501B1 (en) * 1999-12-16 2003-03-25 International Business Machines Corporation Method, system, and program for logging statements to monitor execution of a program
US6584487B1 (en) * 1999-11-16 2003-06-24 Hewlett-Packard Development Company, L.P. Method, system, and apparatus for managing tasks
US6718489B1 (en) * 2000-12-07 2004-04-06 Unisys Corporation Electronic service request generator for automatic fault management system
US6785893B2 (en) * 2000-11-30 2004-08-31 Microsoft Corporation Operating system event tracker having separate storage for interrupt and non-interrupt events and flushing the third memory when timeout and memory full occur
US6801480B2 (en) * 2001-01-22 2004-10-05 Funai Electric Co., Ltd Optical disk drive apparatus capable of braking the optical head at half track short of target track
US6957366B1 (en) * 2001-09-28 2005-10-18 Bellsouth Intellectual Property Corporation System and method for an interactive web-based data catalog for tracking software bugs

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6076166A (en) 1997-01-17 2000-06-13 Philips Electronics North America Corporation Personalizing hospital intranet web sites

Patent Citations (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5884022A (en) * 1996-06-03 1999-03-16 Sun Microsystems, Inc. Method and apparatus for controlling server activation in a multi-threaded environment
US5913041A (en) * 1996-12-09 1999-06-15 Hewlett-Packard Company System for determining data transfer rates in accordance with log information relates to history of data transfer activities that independently stored in content servers
US6138149A (en) * 1997-06-05 2000-10-24 Sony Corporation System for tracking information copied from a web page and sent via electronic mail
US6192382B1 (en) * 1997-09-24 2001-02-20 Mediaone Group, Inc. Method and system for web site construction using HTML fragment caching
US6012066A (en) * 1997-10-01 2000-01-04 Vallon, Inc. Computerized work flow system
US6044398A (en) * 1997-11-21 2000-03-28 International Business Machines Corporation Virtual dynamic browsing system and method for automated web server and testing
US6175838B1 (en) * 1998-04-29 2001-01-16 Ncr Corporation Method and apparatus for forming page map to present internet data meaningful to management and business operation
US6389426B1 (en) * 1999-02-09 2002-05-14 Worldcom, Inc. Central trouble ticket database and system and method for managing same to facilitate ticketing, trending, and tracking processes
US6457142B1 (en) * 1999-10-29 2002-09-24 Lucent Technologies Inc. Method and apparatus for target application program supervision
US6584487B1 (en) * 1999-11-16 2003-06-24 Hewlett-Packard Development Company, L.P. Method, system, and apparatus for managing tasks
US6539501B1 (en) * 1999-12-16 2003-03-25 International Business Machines Corporation Method, system, and program for logging statements to monitor execution of a program
US20020034134A1 (en) * 2000-09-19 2002-03-21 Minoru Hirashima Disk reading apparatus
US6785893B2 (en) * 2000-11-30 2004-08-31 Microsoft Corporation Operating system event tracker having separate storage for interrupt and non-interrupt events and flushing the third memory when timeout and memory full occur
US6718489B1 (en) * 2000-12-07 2004-04-06 Unisys Corporation Electronic service request generator for automatic fault management system
US6801480B2 (en) * 2001-01-22 2004-10-05 Funai Electric Co., Ltd Optical disk drive apparatus capable of braking the optical head at half track short of target track
US6957366B1 (en) * 2001-09-28 2005-10-18 Bellsouth Intellectual Property Corporation System and method for an interactive web-based data catalog for tracking software bugs

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050028145A1 (en) * 2003-07-31 2005-02-03 Sun Microsystems, Inc. Flexible error trace mechanism
US7685573B2 (en) * 2003-07-31 2010-03-23 Sun Microsystems, Inc. Flexible error trace mechanism
US20050154938A1 (en) * 2003-12-19 2005-07-14 International Business Machines Corp. Autonomic method to resume multi-threaded preload imaging process
US7114097B2 (en) * 2003-12-19 2006-09-26 Lenovo (Singapore) Pte. Ltd. Autonomic method to resume multi-threaded preload imaging process
EP1662396A2 (en) * 2004-11-26 2006-05-31 Fujitsu Limited Hardware error control method in an instruction control apparatus having an instruction processing suspension unit
US8862942B2 (en) 2010-12-23 2014-10-14 Intel Corporation Method of system for detecting abnormal interleavings in concurrent programs
WO2012087402A1 (en) * 2010-12-23 2012-06-28 Intel Corporation Method and system for detecting abnormal interleavings in concurrent programs
CN102842007A (en) * 2012-07-16 2012-12-26 腾讯科技(深圳)有限公司 Access control method and system of mobile terminal application program
WO2014012448A1 (en) * 2012-07-16 2014-01-23 Tencent Technology (Shenzhen) Company Limited Method and system for controlling access to applications on mobile terminal
US9141774B2 (en) 2012-07-16 2015-09-22 Tencent Technology (Shenzhen) Company Limited Method and system for controlling access to applications on mobile terminal
US9355230B2 (en) 2012-07-16 2016-05-31 Tencent Technology (Shenzhen) Company Limited Method and system for controlling access to applications on mobile terminal
US20160098342A1 (en) * 2014-10-05 2016-04-07 YScope Inc. Systems and processes for computer log analysis
US9729671B2 (en) * 2014-10-05 2017-08-08 YScope Inc. Systems and processes for computer log analysis
US20180373581A1 (en) * 2017-06-23 2018-12-27 Microsoft Technology Licensing, Llc System and methods for optimal error detection in programmatic environments
US10509694B2 (en) * 2017-06-23 2019-12-17 Microsoft Technology Licensing, Llc System and methods for optimal error detection in programmatic environments
US11449411B2 (en) * 2020-06-02 2022-09-20 Red Hat, Inc. Application-specific log routing

Also Published As

Publication number Publication date
US7017077B2 (en) 2006-03-21

Similar Documents

Publication Publication Date Title
US7017077B2 (en) System and method of error retention for threaded software
US8286139B2 (en) Call stack sampling for threads having latencies exceeding a threshold
US9323578B2 (en) Analyzing wait states in a data processing system
US8949671B2 (en) Fault detection, diagnosis, and prevention for complex computing systems
US8839271B2 (en) Call stack sampling to obtain information for analyzing idle states in a data processing system
US8141053B2 (en) Call stack sampling using a virtual machine
US8132170B2 (en) Call stack sampling in a data processing system
US9032254B2 (en) Real time monitoring of computer for determining speed and energy consumption of various processes
US8566795B2 (en) Selectively obtaining call stack information based on criteria
US5872909A (en) Logic analyzer for software
US7958402B2 (en) Generate diagnostic data for overdue thread in a data processing system
US20100017583A1 (en) Call Stack Sampling for a Multi-Processor System
JPH0774984B2 (en) System resource utilization measurement method and data processing system
US8286134B2 (en) Call stack sampling for a multi-processor system
JP2009516239A (en) General purpose multi-instance method and GUI detection system for tracking and monitoring computer applications
JPH0816877B2 (en) Method and system for real-time capture and reduction of resource data for data processing system
US20130096880A1 (en) System test method
CN111625833A (en) Efficient method and device for judging reuse vulnerability after software program release
US20180337817A1 (en) Performance evaluation of applications that access external resources
US7900196B2 (en) Method and apparatus for monitoring for conditions during execution of code
JP5623557B2 (en) Method, apparatus, and computer program in a multi-threaded computing environment for collecting diagnostic data
US8214693B2 (en) Damaged software system detection
US8046760B2 (en) Lock contention pinpointing
US9910758B2 (en) Computer flight recorder with active error detection
US8762783B2 (en) Error identification

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LOWEN, DANIEL S.;HAYDEN, CLIFFORD O.;REEL/FRAME:012477/0023

Effective date: 20011220

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees
STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20100321