Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20030226056 A1
Publication typeApplication
Application numberUS 10/157,567
Publication dateDec 4, 2003
Filing dateMay 28, 2002
Priority dateMay 28, 2002
Also published asUS7017082
Publication number10157567, 157567, US 2003/0226056 A1, US 2003/226056 A1, US 20030226056 A1, US 20030226056A1, US 2003226056 A1, US 2003226056A1, US-A1-20030226056, US-A1-2003226056, US2003/0226056A1, US2003/226056A1, US20030226056 A1, US20030226056A1, US2003226056 A1, US2003226056A1
InventorsMichael Yip, Anna Berenberg
Original AssigneeMichael Yip, Anna Berenberg
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Method and system for a process manager
US 20030226056 A1
Abstract
A method and system is provided for monitoring the health of processes running on a router. A behavior of a process is monitored and the process is killed if the behavior is abnormal. The behavior may be abnormal if the process is non-responsive, cannot start, or repeatedly crashes. The system may include a timer to measure a predetermined time interval for the process to perform a desired action, a counter to count a number of times the process fails to perform the desired action before the timer expires, and a controller to kill the process when the counter exceeds a maximum number of failures. Alternatively, the timer could measure an amount of uptime, the counter could count the number of times the process crashes, and the controller could kill the process when a crash rate calculated from the number of times the process crashes per the amount of uptime exceeds a maximum crash rate.
Images(9)
Previous page
Next page
Claims(28)
What is claimed is:
1. A method comprising:
starting a process;
monitoring a behavior of the process; and
killing the process when the behavior is abnormal.
2. The method of claim 1, further comprising notifying an administrator about the abnormal behavior.
3. The method of claim 1, wherein the behavior is abnormal when the process cannot start, and wherein monitoring the behavior comprises:
setting a startup timer before starting the process; and
incrementing a startup count when the process fails to register before the startup timer expires,
and wherein killing the process comprises killing the process when the startup count exceeds a maximum number of attempts at starting the process.
4. The method of claim 3, further comprising attempting to restart the process when the startup count does not exceed the maximum number of attempts at starting the process.
5. The method of claim 3, further comprising cleaning up internal process control data and notifying an administrator about the inability to start the process when the startup count exceeds a maximum number of attempts at starting the process.
6. The method of claim 1, wherein the behavior is abnormal when the process repeatedly crashes, and wherein monitoring the behavior comprises:
accumulating an amount of uptime for the process;
incrementing a crash count when the process crashes; and
calculating a crash rate from the crash count per the amount of uptime,
and wherein killing the process comprises killing the process when the calculated crash rate exceeds a maximum crash rate.
7. The method of claim 6, further comprising attempting to restart the process when the crash rate does not exceed the maximum crash rate.
8. The method of claim 6, further comprising cleaning up internal process control data and notifying an administrator about the inability to start the process when the crash rate exceeds a maximum crash rate.
9. The method of claim 1, wherein the behavior is abnormal when the process is non-responsive, and wherein monitoring the behavior comprises:
setting a process timer after starting the process;
registering the process and incrementing a timeout count when the process fails to register before the process timer expires; and
polling the process and incrementing the timeout count when the process fails to respond to polling before the process timer expires,
and wherein killing the process comprises killing the process when the timeout count exceeds a maximum number of timeouts.
10. The method of claim 9, further comprising resetting the timeout count each time the process responds to polling.
11. The method of claim 9, wherein polling the process and incrementing the timeout count when the process fails to respond to polling before the process timer expires comprises sending a message to the process and incrementing the timeout count when the process fails to reply to the sent message before the process timer expires.
12. The method of claim 10, wherein resetting the timeout count each time the process responds to polling comprises resetting the timeout count to zero each time the process replies to the sent message.
13. The method of claim 1, wherein the behavior is abnormal when a thread of the process is non-responsive, and wherein monitoring the behavior comprises:
setting a thread timer for each thread after registering the process;
waiting for each thread to provide an updated status; and
incrementing a corresponding thread timeout count when any of the threads fails to provide an updated status before the corresponding thread timer expires,
and wherein killing the process comprises killing the process when any of the thread timeout counts exceeds a maximum number of timeouts.
14. The method of claim 13, further comprising incrementing the timeout counts when the process fails to register before any of the thread timers expire.
15. The method of claim 13, further comprising incrementing the timeout counts when the process fails to send a message before any of the thread timers expire.
16. The method of claim 13, further comprising resetting the thread timeout count each time a corresponding thread provides an updated status.
17. An apparatus comprising:
a process monitor to monitor a behavior of a process; and
a controller to kill the process when the behavior is abnormal.
18. The apparatus of claim 17, further comprising a timer to measure a predetermined time interval for the process to perform a desired action and a counter to count a number of times the process fails to perform the desired action before the timer expires, and wherein a controller to kill the process comprises a controller to kill the process when the counter exceeds a maximum number of failures.
19. The apparatus of claim 18, wherein the desired action is to respond to polling and wherein the counter to increment each time the process does not respond to polling before the timer expires.
20. The apparatus of claim 18, wherein the desired action is to provide an update on the status of a thread of the process and wherein the counter to increment each time a thread of the process does not provide an updated status before the timer expires.
21. The apparatus of claim 18, wherein the desired action is to register and wherein the counter to increment each time the process does not register before the timer expires.
22. The apparatus of claim 17, further comprising a timer to measure an amount of uptime, a counter to count the number of times the process crashes, and a calculator to measure a crash rate from the number of times the process crashes per the amount of uptime, and wherein a controller to kill the process comprises a controller to kill the process when the calculated crash rate exceeds a predetermined maximum crash rate.
23. An article of manufacture comprising:
a machine accessible medium comprising content that when accessed by a machine causes the machine to:
start a process;
monitor a behavior of the process; and
kill the process when the behavior is abnormal.
24. The article of manufacture of claim 24, further comprising a machine accessible medium comprising content that when accessed by a machine causes the machine to notify an administrator about the abnormal behavior.
25. The article of manufacture of claim 24, wherein the behavior is abnormal when the process cannot start, and wherein monitoring the behavior comprises:
setting a startup timer before starting the process; and
incrementing a startup count when the process fails to register before the startup timer expires,
and wherein killing the process comprises killing the process when the startup count exceeds a maximum number of attempts at starting the process.
26. The article of manufacture of claim 24, wherein the behavior is abnormal when the process repeatedly crashes, and wherein monitoring the behavior comprises:
accumulating an amount of uptime for the process;
incrementing a crash count when the process crashes; and
calculating a crash rate from the crash count per the amount of uptime,
and wherein killing the process comprises killing the process when the crash rate exceeds a maximum crash rate.
27. The article of manufacture of claim 24, wherein the behavior is abnormal when the process is non-responsive, and wherein monitoring the behavior comprises:
setting a process timer after starting the process;
registering the process and incrementing a timeout count when the process fails to register before the process timer expires; and
polling the process and incrementing the timeout count when the process fails to respond to polling before the process timer expires,
and wherein killing the process comprises killing the process when the timeout count exceeds a maximum number of timeouts.
28. The article of manufacture of claim 24, wherein the behavior is abnormal when a thread of the process is non-responsive, and wherein monitoring the behavior comprises:
setting a thread timer for each thread after registering the process; and
waiting for each thread to provide an updated status and incrementing a timeout count when any of the threads fail to provide an updated status before the corresponding thread timer expires,
and killing the process comprises killing the process when the timeout count exceeds a maximum number of timeouts.
Description
    BACKGROUND
  • [0001]
    1. Technical Field
  • [0002]
    The invention relates to the field of network management. In particular, the invention relates to a process manager that monitors the health of processes running on a router.
  • [0003]
    2. Background Information and Description of Related Art
  • [0004]
    The architecture of high-performance Internet routers has advanced in the last several years to provide increased performance in routing ever-greater volumes of network traffic. It is not uncommon for a router to support numerous protocols as well as several applications for configuration and maintenance of the router tables, protocols, and network policies. These advances have increased the complexity of the router such that the management of applications and protocols running on the router is critical for reliable network performance.
  • [0005]
    In existing router management technology, the logic to support the applications, protocols, and associated management interfaces is centrally managed in a single master program. This can result in a single point of failure, meaning that even if there is a problem with only one protocol or application or interface, the entire program could crash, bringing the router down with it. In addition, if the master program needs to be updated, for example to accommodate a new protocol, then the master program must be brought down in order to perform the updates, thereby temporarily taking the router out of service.
  • [0006]
    In an effort to overcome some of the limitations in existing router management technology, management of applications, protocols, and associated management interfaces may be decentralized. However, this means that there will be several independent processes running simultaneously on both the active Router Protocol (RP) and line cards. These multiple processes share the resources of the processor on which they are running. Furthermore, processes often run multiple threads per process. These threads share the same address space and may be short or long-lived. Therefore, if any one process or any thread of a process is not healthy, it could be taking up valuable resources unnecessarily.
  • SUMMARY
  • [0007]
    According to one aspect of the invention, a method and system is provided to monitor the health of processes and to kill the process when the process is unhealthy. The system starts a process, monitors a behavior of the process, and kills the process when the behavior is abnormal.
  • [0008]
    According to one aspect of the invention, the behavior is abnormal when the process is non-responsive. The behavior of the process is monitored by setting a process timer after starting the process, registering the process and incrementing a timeout count when the process fails to register before the process timer expires, and polling the process and incrementing the timeout count when the process fails to respond to polling before the process timer expires. The process is killed when the timeout count exceeds a maximum number of timeouts.
  • [0009]
    According to one aspect of the invention, the behavior is abnormal when a thread of the process is non-responsive. The behavior of the process is monitored by setting up a thread timer for each thread of the process after registering the process, waiting for each thread to provide an updated status, and incrementing a corresponding thread timeout count when any of the threads fails to provide an updated status before the corresponding thread timer expires. The process is killed when any of the thread timeout counts exceeds a maximum number of timeouts.
  • [0010]
    According to one aspect of the invention, the behavior is abnormal when the process cannot start. The behavior of the process is monitored by setting a startup timer before starting the process and incrementing a startup count when the process fails to register before the startup timer expires. The process is killed when the startup count exceeds a maximum number of attempts at starting the process.
  • [0011]
    According to one aspect of the invention, the behavior is abnormal when the process repeatedly crashes. The behavior of the process is monitored by accumulating an amount of uptime for the process, incrementing a crash count when the process crashes, and calculating a crash rate from the crash count per the amount of uptime. The process is killed when the calculated crash rate exceeds a maximum crash rate.
  • [0012]
    According to one aspect of the invention, apparatus are provided to carry out the above and other methods.
  • BRIEF DESCRIPTION OF DRAWINGS
  • [0013]
    The invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.
  • [0014]
    [0014]FIG. 1 illustrates is a block diagram illustrating one generalized embodiment of a process management system incorporating the invention, and the operating environment in which certain aspects of the illustrated invention may be practiced.
  • [0015]
    [0015]FIG. 2 is a block diagram illustrating selected components of the process management system of FIG. 1 in further detail, in accordance with one embodiment of the invention.
  • [0016]
    [0016]FIG. 3 is a block diagram illustrating a suitable computing environment in which certain aspects of the illustrated invention may be practiced.
  • [0017]
    [0017]FIG. 4 is a flow diagram illustrating certain aspects of a method to be performed by a computer executing one embodiment of the illustrated invention.
  • [0018]
    [0018]FIG. 5 is a flow diagram illustrating one embodiment of monitoring a behavior of a process in further detail.
  • [0019]
    [0019]FIG. 6 is a flow diagram illustrating an alternative embodiment of monitoring a behavior of a process in further detail.
  • [0020]
    [0020]FIG. 7 is a flow diagram illustrating another alternative embodiment of monitoring a behavior of a process in further detail.
  • [0021]
    [0021]FIG. 8 is a flow diagram illustrating yet another alternative embodiment of monitoring a behavior of a process in further detail.
  • DETAILED DESCRIPTION
  • [0022]
    In the following description various aspects of the present invention, a method and apparatus for process management will be described. Specific details will be set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the present invention may be practiced with only some or all of the described aspects of the present invention, and with or without some or all of the specific details. In some instances, well known architectures, steps, and techniques have not been shown to avoid unnecessarily obscuring the present invention. For example, specific details are not provided as to whether the method and apparatus is implemented in a switch, router, bridge, server or gateway, as a software routine, hardware circuit, firmware, or a combination thereof.
  • [0023]
    Parts of the description will be presented using terminology commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art, including terms of operations performed by a network operating system, and their operands, such as transmitting, receiving, routing, packets, messages, tables, command, message information base, command trees, tags and the like. As well understood by those skilled in the art, these operands take the form of electrical, magnetic, or optical signals, and the operations involve storing, transferring, combining, and otherwise manipulating the signals through electrical, magnetic or optical components of a system. The term system includes general purpose as well as special purpose arrangements of these components that are standalone, adjunct or embedded.
  • [0024]
    Various operations will be described as multiple discrete steps performed in turn in a manner that is most helpful in understanding the present invention. However, the order of description should not be construed as to imply that these operations are necessarily performed in the order they are presented, or even order dependent. Lastly, repeated usage of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may.
  • [0025]
    It should be noted that while the description that follows addresses the method and apparatus as it applies to a network device such as a router, or layer 3 switch, it is appreciated by those of ordinary skill in the art that method is generally applicable to any packet forwarding device, including a bridge (layer 2 switch), server or gateway. It should also be noted that while the method and apparatus may be discussed in the context of a local area network (LAN), the present invention may also be used in the context of other Transport Control Protocol/Internet Protocol (TCP/IP)-based networks including, but not limited to, internetworks, Virtual Local Area Networks (VLANs), Metropolitan Area Networks (MANs), and Wide Area Networks (WANs), as well as networks organized into subnets.
  • [0026]
    [0026]FIG. 1 is a block diagram illustrating one generalized embodiment of a process management system 100 incorporating the invention, and the operating environment in which certain aspects of the illustrated invention may be practiced. The system 100 is shown to be operating in an active Route Processor (RP) card and a line card running multiple virtual routers. Those of ordinary skill in the art will appreciate that the system 100 may include more components than those shown in FIG. 1. However, it is not necessary that all of these generally conventional components be shown in order to disclose an illustrative embodiment for practicing the invention. As illustrated, the process management system 100 operates on a router that has a process manager 102.
  • [0027]
    A typical router supports a number of applications that support protocols, network interfaces, and other components, the operation of which is maintained by the process manager 102. For example, in the illustrated embodiment, the router includes applications to support the Border Gateway Protocol (BGP) 106 and the Open Shortest Path First protocol (OSPF) 108.
  • [0028]
    Each application may also support one or more management interfaces, such as command line interface (CLI) 110, Simple Network Management Protocol (SNMP), or Extensible Markup Language (XML) based management interfaces. The management interfaces provide network administrators with access to the functions of the router and router applications using CLI commands, or SNMP or XML requests to update or access configuration of the process manager.
  • [0029]
    [0029]FIG. 2 is a block diagram illustrating selected components of the process management system of FIG. 1 in further detail. The process manager 102 uses a configuration file 104 to allow the process manager to be configurable to set various options. The configuration file 104 may be implemented in various formats, such as a flat file, a CLI, or an XML file.
  • [0030]
    Process manager 102 includes a process monitor 202 to monitor a behavior of a process and a controller 204 to control the process and kill the process when the behavior is abnormal. In one embodiment, the process manager 102 includes one or more timers 206. One timer may measure a predetermined time interval for a process to perform a desired action, such as responding to polling or registering the process upon startup. Another timer may measure the amount of uptime for the process. In one embodiment, the process manager 102 includes one or more counters 208. One counter may count a number of times a process fails to perform the desired action during the predetermined time interval. In one embodiment, the controller 204 kills a process when the counter exceeds a maximum number of failures. Another counter may count the number of times a process crashes. The process manager 102 may further include a calculator 210 to measure a crash rate from the number of times a process crashes per the amount of uptime. In one embodiment, the controller 204 kills a process when the calculated crash rate exceeds a predetermined maximum crash rate. The configuration file 104 may be used to set the predetermined time interval, maximum number of failures, maximum crash rate, or other configurable options.
  • [0031]
    [0031]FIG. 3 is a block diagram illustrating a suitable computing environment in which certain aspects of the illustrated invention may be practiced. In one embodiment, the method for a process management system 100 may be implemented on a computer system 300 having components 302-312, including a processor 302, a memory 304, an Input/Output device 306, a data storage 312, and a network interface 310, coupled to each other via a bus 308. The components perform their conventional functions known in the art and provide the means for implementing the process management system 100. Collectively, these components represent a broad category of hardware systems, including but not limited to general purpose computer systems and specialized packet forwarding devices. It is to be appreciated that various components of computer system 300 may be rearranged, and that certain implementations of the present invention may not require nor include all of the above components. Furthermore, additional components may be included in system 300, such as additional processors (e.g., a digital signal processor), storage devices, memories, and network or communication interfaces.
  • [0032]
    [0032]FIG. 4 is a flowchart illustrating certain aspects of a method to be performed by a computer executing one embodiment of the invention. The methods to be performed by a processor on a router or other network device constitute computer programs made up of computer-executable instructions. Describing the methods by reference to a flowchart enables one skilled in the art to develop such programs including such instructions to carry out the methods on suitably configured computers, in which the processor of the computer execute the instructions from computer-accessible media. The computer-executable instructions may be written in a computer programming language or may be embodied in firmware logic such as an application-specific integrated circuit (ASIC). If written in a programming language conforming to a recognized standard, such instructions can be executed on a variety of hardware platforms and for interface to a variety of operating systems. In addition, the invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. Furthermore, it is common in the art to speak of software, in one form or another, for example a program, procedure, process, or application, as taking an action or causing a result. Such expressions are merely a shorthand way of saying that execution of the software by a computer causes the processor of the computer to perform an action or a produce a result.
  • [0033]
    The method begins at 400, where a process is started. The process may be running in any of the applications, protocols, or management interfaces managed by process manager 102. At 402, a behavior of the process is monitored. At 404, the process is killed when the behavior is abnormal. In one embodiment, an administrator is notified about the abnormal behavior.
  • [0034]
    [0034]FIG. 5 is a flowchart illustrating one embodiment of monitoring a behavior of a process in further detail. At 500, a maximum startup count is set to define a maximum number of startup attempts for the process. At 502, a startup timer is set to define a time interval to wait for the process to startup and register. At 504, the process manager 102 determines whether the timer has expired. When the timer has not yet expired, the waiting continues at 506 until the timer expires. When the timer expires, at 508, the process manager 102 determines whether the process has registered. When the process has registered, the behavior of the process is normal. When process has not registered when the timer expires, at 510, the startup count is incremented. Then, at 512, the process manager 102 determines whether the process has reached the maximum startup count. When the process has not yet reached the maximum startup count, then the process is restarted at 514, and the method is reiterated from 502. When the process has reached the maximum startup count, then the behavior of the process is abnormal, and the process is killed. Internal process control data may then be cleaned up and an administrator may be notified about the inability to start the process.
  • [0035]
    [0035]FIG. 6 is a flowchart illustrating an embodiment of monitoring a behavior of a process in further detail. At 600, a maximum timeout count is set to define a maximum number of timeouts for the process. At 602, a timer is set to define a time interval to wait for the process to respond to polling. At 604, the process is polled. An example of polling is to send a “hello” message to the process. The process may reply by sending a “hello acknowledgment” message. At 606, the process manager 102 determines whether the timer has expired. When the timer has not yet expired, the waiting continues at 608 until the timer expires. When the timer expires, at 610, the process manager 102 determines whether the process has registered. When the process has registered, at 612, the process manager 102 determines whether the process has responded to polling. When the process has responded to polling, at 614, the timeout count is reset, and the method is reiterated from 604. When the process has not registered or the process has not responded to polling when the timer expires, at 616, the timeout count is incremented. Then, at 618, the process manager 102 determines whether the process has reached the maximum timeout count. When the process has not yet reached the maximum timeout count, the method is reiterated from 604. When the process has reached the maximum timeout count, then the behavior of the process is abnormal, and the process is killed.
  • [0036]
    [0036]FIG. 7 is a flowchart illustrating an embodiment of monitoring a behavior of a process in further detail. At 700, a maximum thread timeout count is set to define a maximum number of timeouts for the threads of the process. At 702, a thread timer is set for each thread in the process to define a time interval to wait for each thread to provide an updated status. At 704, the process manager 102 waits for each thread to provide an updated status. At 706, the process manager 102 determines whether the corresponding thread timer has expired. When the timer has not yet expired, the waiting continues at 708 until the timer expires. When the timer expires, at 710, the process manager 102 determines whether the process has registered. When the process has registered, at 712, the process manager 102 determines whether the thread has provided an updated status. When the thread has provided an updated status, the corresponding thread timeout count is reset at 714, and the method is reiterated from 704. When the process has not registered or the thread has not provided an updated status when the timer expires, at 716, the corresponding thread timeout count is incremented. Then, at 718, the process manager 102 determines whether the thread of the process has reached the maximum thread timeout count. When the thread has not yet reached the maximum thread timeout count, the method is reiterated from 704. When the thread has reached the maximum thread timeout count, then the behavior of the process is abnormal, and the process is killed.
  • [0037]
    [0037]FIG. 8 is a flowchart illustrating one embodiment of monitoring a behavior of a process in further detail. At 800, a maximum crash rate for the process is set. At 802, the amount of uptime for the process is accumulated. At 804, the process manager 102 determines whether the process has crashed. When the process has not crashed, the method is reiterated at 802. When the process crashes, at 806, the crash count is incremented. Then, at 808, the crash rate is calculated from the crash count per the amount of uptime. Then, at 810, the process manager 102 determines whether the process has reached the maximum crash rate. When the process has not yet reached the maximum crash rate, the process is restarted at 812, and the method is reiterated from 802. When the process has reached the maximum crash rate, the behavior of the process is abnormal, and the process is killed. Internal process control data may then be cleaned up and an administrator may be notified about the inability to start the process.
  • [0038]
    As will be appreciated by those skilled in the art, the content for implementing an embodiment of the method of the invention, for example, computer program instructions, may be provided by any machine-readable media which can store data that is accessible by system 100, as part of or in addition to memory, including but not limited to cartridges, magnetic cassettes, flash memory cards, digital video disks, random access memories (RAMs), read-only memories (ROMs), and the like. In this regard, the system 100 is equipped to communicate with such machine-readable media in a manner well-known in the art.
  • [0039]
    It will be further appreciated by those skilled in the art that the content for implementing an embodiment of the method of the invention may be provided to the system 100 from any external device capable of storing the content and communicating the content to the system 100. For example, in one embodiment, the system 100 may be connected to a network, and the content may be stored on any device in the network.
  • [0040]
    The above description of illustrated embodiments of the invention, including what is described in the abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
  • [0041]
    These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US6425093 *Jan 4, 1999Jul 23, 2002Sophisticated Circuits, Inc.Methods and apparatuses for controlling the execution of software on a digital processing system
US6453430 *May 6, 1999Sep 17, 2002Cisco Technology, Inc.Apparatus and methods for controlling restart conditions of a faulted process
US6662310 *Nov 10, 1999Dec 9, 2003Symantec CorporationMethods for automatically locating url-containing or other data-containing windows in frozen browser or other application program, saving contents, and relaunching application program with link to saved data
US6665758 *Oct 4, 1999Dec 16, 2003Ncr CorporationSoftware sanity monitor
US20020162053 *May 17, 2002Oct 31, 2002Os Ron VanUser transparent software malfunction detection and reporting
US20030037172 *Aug 17, 2001Feb 20, 2003John LacombeHardware implementation of an application-level watchdog timer
US20030074605 *Jul 19, 2002Apr 17, 2003Hitachi, Ltd.Computer system and method for program execution monitoring in computer system
US20040054984 *Apr 8, 2003Mar 18, 2004Chong James C.Method and system for problem determination in distributed enterprise applications
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7313735 *Apr 30, 2004Dec 25, 2007Sun Microsystems, Inc.In-line server health checking
US7506209 *May 25, 2005Mar 17, 2009Fujitsu LimitedComputer shutoff condition monitoring method, information processing apparatus, program and computer readable information recording medium
US8281108 *Jan 20, 2003Oct 2, 2012Martin VorbachReconfigurable general purpose processor having time restricted configurations
US8281265Nov 19, 2009Oct 2, 2012Martin VorbachMethod and device for processing data
US8301872May 4, 2005Oct 30, 2012Martin VorbachPipeline configuration protocol and configuration unit communication
US8310274Mar 4, 2011Nov 13, 2012Martin VorbachReconfigurable sequencer structure
US8312200Jul 21, 2010Nov 13, 2012Martin VorbachProcessor chip including a plurality of cache elements connected to a plurality of processor cores
US8312301Sep 30, 2009Nov 13, 2012Martin VorbachMethods and devices for treating and processing data
US8365014 *Jan 14, 2010Jan 29, 2013Juniper Networks, Inc.Fast resource recovery after thread crash
US8407525Oct 24, 2011Mar 26, 2013Pact Xpp Technologies AgMethod for debugging reconfigurable architectures
US8429385Sep 19, 2002Apr 23, 2013Martin VorbachDevice including a field having function cells and information providing cells controlled by the function cells
US8468329Jun 8, 2012Jun 18, 2013Martin VorbachPipeline configuration protocol and configuration unit communication
US8471593Nov 4, 2011Jun 25, 2013Martin VorbachLogic cell array and bus system
US8627142 *Jan 11, 2013Jan 7, 2014Juniper Networks, Inc.Fast resource recovery after thread crash
US8686475Feb 9, 2011Apr 1, 2014Pact Xpp Technologies AgReconfigurable elements
US8686549Sep 30, 2009Apr 1, 2014Martin VorbachReconfigurable elements
US8706855Aug 16, 2010Apr 22, 2014Apple Inc.Method and apparatus for idling a network connection
US8726250Mar 10, 2010May 13, 2014Pact Xpp Technologies AgConfigurable logic integrated circuit having a multidimensional structure of configurable elements
US8803552Sep 25, 2012Aug 12, 2014Pact Xpp Technologies AgReconfigurable sequencer structure
US8819505Jun 30, 2009Aug 26, 2014Pact Xpp Technologies AgData processor having disabled cores
US8869121Jul 7, 2011Oct 21, 2014Pact Xpp Technologies AgMethod for the translation of programs for reconfigurable architectures
US8914590Sep 30, 2009Dec 16, 2014Pact Xpp Technologies AgData processing method and device
US9021310 *Feb 14, 2012Apr 28, 2015Amazon Technologies, Inc.Policy-driven automatic network fault remediation
US9075605Oct 17, 2012Jul 7, 2015Pact Xpp Technologies AgMethods and devices for treating and processing data
US20060090062 *Jan 20, 2003Apr 27, 2006Martin VorbachReconfigurable processor
US20060179353 *May 25, 2005Aug 10, 2006Fujitsu LimitedComputer shutoff condition monitoring method, information processing apparatus, program and computer readable information recording medium
US20070294584 *Apr 28, 2006Dec 20, 2007Microsoft CorporationDetection and isolation of data items causing computer process crashes
US20080155544 *Dec 20, 2007Jun 26, 2008ThalesDevice and method for managing process task failures
US20100281235 *Nov 17, 2008Nov 4, 2010Martin VorbachReconfigurable floating-point and bit-level data processing unit
US20110119657 *Dec 8, 2008May 19, 2011Martin VorbachUsing function calls as compiler directives
US20110161977 *Mar 23, 2010Jun 30, 2011Martin VorbachMethod and device for data processing
US20110173483 *Jan 14, 2010Jul 14, 2011Juniper Networks Inc.Fast resource recovery after thread crash
US20110173596 *Nov 28, 2008Jul 14, 2011Martin VorbachMethod for facilitating compilation of high-level code for varying architectures
US20130132773 *Jan 11, 2013May 23, 2013Juniper Networks, Inc.Fast resource recovery after thread crash
USRE44365Oct 21, 2010Jul 9, 2013Martin VorbachMethod of self-synchronization of configurable elements of a programmable module
USRE45109Oct 21, 2010Sep 2, 2014Pact Xpp Technologies AgMethod of self-synchronization of configurable elements of a programmable module
USRE45223Oct 21, 2010Oct 28, 2014Pact Xpp Technologies AgMethod of self-synchronization of configurable elements of a programmable module
CN100555228CNov 8, 2006Oct 28, 2009中兴通讯股份有限公司Monitoring method of embedded LINUX applications progress
CN103503374A *Nov 15, 2011Jan 8, 2014华为技术有限公司Monitoring method and device, and network device
EP1640865A2 *Jun 24, 2005Mar 29, 2006Evolium S.A.S.Process management system
WO2011087924A1 *Jan 3, 2011Jul 21, 2011Apple Inc.Method and apparatus for idling a network connection
Classifications
U.S. Classification714/4.1, 714/E11.004, 714/E11.003
International ClassificationH04L1/22, G06F11/00
Cooperative ClassificationH04L43/16, H04L41/0213, H04L43/0817, G06F11/076, G06F11/0715, G06F11/0757, H04L12/2692
European ClassificationG06F11/07P2A1, G06F11/07P2A2, G06F11/07P1C, H04L43/08D
Legal Events
DateCodeEventDescription
May 28, 2002ASAssignment
Owner name: EXTREME NETWORKS, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:YIP, MICHAEL;BERENBERG, ANNA;REEL/FRAME:012945/0638
Effective date: 20020516