Detecting upset conditions in application instances

• US 9,264,338 B1
• Filed: 04/08/2013
• Issued: 02/16/2016
• Est. Priority Date: 04/08/2013
• Status: Active Grant

• Current Assignee: T-Mobile Innovations LLC (Deutsche Telekom AG)
• Original Assignee: Sprint Communications Company LP (Deutsche Telekom AG)
• Inventors: Leonard, Mark D., Carlton, Jennifer Mae
• Primary Examiner(s): Baturay, Alicia
• Application Number:
  US13/858,528
• Time in Patent Office: 1,044 Days
• Field of Search: 709/224
• US Class Current: 1/1
• CPC Class Codes: H04L 41/0681 Configuration of triggering conditions
• CPC Class Codes: H04L 43/08 Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters

Abstract

A method, system and a computer-readable media for automatically detecting problems in an application instance are provided. The application instances are responsible for communicating messages accumulating within a queue to a destination. The destination may be a computer application, another queue, or some other computing component. In one embodiment, the queue and application instances are part of a messaging-middleware environment. An embodiment of the present invention monitors the performance of individual application instances and detects an upset condition by comparing the present performance with a baseline performance or normal performance range. The application instance'"'"'s message transfer rate may be used to measure both present and normal performance.

Claims

1. One or more non-transitory computer-readable media having computer-executable instructions embodied thereon for performing a method of detecting a malfunction in an application responsible for withdrawal of messages from a queue, the method comprising;

determining a normal message transfer rate for an application instance that communicates messages from a queue wherein the normal message transfer rate is determined by dividing a quantity of messages withdrawn from the queue during a testing period by an amount of time comprising the testing period to obtain an outgoing message withdrawal rate and further dividing the outgoing message withdrawal rate by a number of active application instances;

monitoring a present message transfer rate for the application instance;

determining that an upset condition exists for the application instance when the present message transfer rate is less than the normal message transfer rate by more than a threshold amount; and

in response to said determining the upset condition exists, generating an upset response event.

2. The media of claim 1, wherein the upset response event is transmitting an alarm message to a designated responder.

3. The media of claim 1, wherein the upset response event comprises checking queue depth to determine whether a lack of messages within the queue caused the upset condition.

4. The media of claim 3, wherein the upset response event further comprises automatically shutting down one or more application instances upon determining a queue depth is below a queue depth threshold.

5. The media of claim 1, wherein the upset response event comprises checking whether an upset condition has been generated for other active application instances communicating messages from the queue and taking no remedial action on the application instance when upset conditions have been generated for multiple active application instances.

6. The media of claim 1, wherein the queue is associated with a messaging-middleware application.

7. One or more non-transitory computer-readable media having computer-executable instructions embodied thereon for performing a method of detecting a malfunction in an application responsible for withdrawal of messages from a queue, the method comprising:

determining a normal message transfer rate by dividing a quantity of messages withdrawn from the queue during a testing period by an amount of time comprising the testing period to obtain an outgoing message withdrawal rate and further dividing the outgoing message withdrawal rate by a number of active application instances;

establishing a normal performance range around the normal transfer rate with a threshold number;

receiving a message transfer rate describing how many messages have been communicated out of a queue by the application instance during a period of time;

comparing the message transfer rate with the normal performance range for the application instance; and

when the message transfer rate is outside the normal performance range, transmitting an alarm message indicating that a malfunction affecting the application instance is present.

8. The media of claim 7, wherein the threshold number is large enough to include within the normal performance range is a range of transfer rates achieved by the application instance during a period when the application instance is determined to be malfunction-free.

9. The media of claim 7, wherein the threshold number is large enough to include within the normal performance range a range of transfer rates expected for an application instance running on a computing device having a particular computing profile.

10. The media of claim 7, wherein the threshold number is large enough to include within the normal performance range an average individual range of transfer rates achieved by a group of application instances during a period when the group of application instances is determined to be malfunction-free.

11. The media of claim 7, wherein the message transfer rate is outside of the normal performance range when a difference is greater than the threshold number.

12. The media of claim 7, wherein the alarm message is transmitted to a component that contacts a designated responder who is responsible for components associated with the queue.

13. A method of detecting a malfunction in an application responsible for withdrawal of messages from a queue, the method comprising;

monitoring a present message transfer rate for an application instance that communicates messages from a messaging-middleware queue;

determining a normal message transfer rate by dividing a quantity of messages withdrawn from the queue during a testing period by an amount of time comprising the testing period to obtain an outgoing message withdrawal rate and further dividing the outgoing message withdrawal rate by a number of active application instances;

determining that an upset condition exists for the application instance when the present message transfer rate is less than the normal message transfer rate by more than a threshold amount; and

in response to said determining the upset condition exists, automatically troubleshooting the upset condition.

14. The method of claim 13, wherein the troubleshooting comprises checking queue depth to determine whether a lack of messages within the queue caused the upset condition.

15. The method of claim 13, wherein the troubleshooting comprises checking whether an upset condition has been generated for other active application instances communicating messages from the queue and taking no remedial action on the application instance when upset conditions have been generated for multiple active application instances.