Browse Prior Art Database

Implementation of "Trace Events" for Software Testing Problem Determination

IP.com Disclosure Number: IPCOM000010725D
Original Publication Date: 2003-Jan-15
Included in the Prior Art Database: 2003-Jan-15
Document File: 1 page(s) / 38K

Publishing Venue

IBM

Abstract

In today's Systems Management product offerings, many products rely on receiving events from remote locations to inform an administrator of a particular problem. But what happens when an event cannot make it from the remote location to the administrator's console? There are network management products that help determine if the problem is a network problem, but what if it is a software problem? This disclosure describes a way to autonomically address this latter situation through "trace events."

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 1

Implementation of "Trace Events" for Software Testing Problem Determination

   This idea is an extension of the "heartbeat" idea that several Systems Management products utilize. The term "heartbeat" refers to remote agents (monitors) in the IT environment that send an occasional heartbeat to an administrator's console to confirm that the agent is still running (especially useful when no other events are being sent by the agent during those times when everything on the agent's device is operating normally). If the heartbeat is not received after a certain period of time, then the administrator assumes that there is an error condition somewhere in the environment and starts looking for possible causes.

The extension of this "heartbeat" idea concerns the creation of "trace ** events" -- events that have additional abilities included so that each event can ascertain whether it completes its trek from a remote agent to an administrator's console. If the event is sent from a remote location but fails to make it past an intermediate point, the event carries with it the ability to interact with software at the intermediate point. For example, the event determines that it has not been forwarded from an intermediate location within a certain period of time, it can "signal" the software at the intermediate location to begin troubleshooting procedures, or the event could possibly reconfigure the networking parameters to use a different port for the forwarding of events, or may...