Managing queue capacity in a messaging queue in a computing environment
View Patent ↗A method and system for automatically managing alarms in an environment where a period of time could pass before the cause of the alarm is addressed is explained herein. The method includes automatically increasing the maximum depth of a queue (i.e. the maximum capacity of a queue to store data) in response to an indication that the current depth of the queue exceeds a high-level alarm setting. Upon determining that the depth of the queue has fallen below the original high-level alarm setting, the maximum depth of the queue is automatically returned to the original maximum setting. In addition, a low-level alarm may be disabled in conjunction with increasing the maximum depth and reactivated upon returning the maximum queue depth to the original setting.
1. One or more computer-readable media having computer-executable instructions embodied thereon for performing a method of automatically managing alarms in an environment where a period of time could pass before the cause of the alarm is addressed, the method comprising;
receiving information indicating that a depth level of a queue exceeds an original high-depth-alarm setting, wherein the depth level is a measure of data within the queue, wherein the original high-depth-alarm setting is a first percentage of a maximum depth;
increasing the maximum depth of the queue from an original maximum setting to an updated maximum setting that is larger than the original maximum setting, thereby
(1) allowing the queue to receive additional messages while a cause of a high-depth condition receives user attention, and
(2) preventing disruption to a process of transferring messages to the queue;
disabling a low-depth alarm for the queue that generates an alarm when the depth level crosses from above a low-depth-alarm setting to below the low-depth-alarm setting, wherein the low-depth-alarm setting is a second percentage of the maximum depth; and
storing an indication that the maximum depth of the queue was increased, such that the maximum depth may be reset upon determining that the cause of the high-depth condition is resolved.
2. The media of claim 1 , further comprising:
determining that a current depth level for the queue is less than the original high-depth-alarm setting;
incident to said determining,
(1) changing the maximum depth from the updated maximum setting to the original maximum setting and
(2) enabling the low-depth alarm for the queue.
3. The media of claim 1 , wherein said storing comprises:
generating an entry in a data store that includes at least queue identification information, the original maximum setting, the original high-depth-alarm setting, and a reset-request indication field that includes a first indication that indicates the maximum depth was increased and not reset.
4. The media of claim 3 , further comprising:
determining that a current depth level for the queue is less than the original high-depth-alarm setting;
incident to said determining, changing the maximum depth from the updated maximum setting to the original maximum setting.
5. The media of claim 4 , further comprising:
incident to said changing, modifying the reset-request indication field to a second indication that indicates the maximum depth was reset.
6. The media of claim 1 , wherein the queue is a messaging-middleware queue.
7. The media of claim 1 , wherein the information originates from one or more of an event generated by a queue manager and a queue monitoring component that generates alarm messages.
8. One or more computer-readable media having computer-executable instructions embodied thereon for performing a method of automatically managing alarms in an environment where a period of time could pass before the cause of the alarm is addressed, the method comprising;
receiving information indicating that a depth level of a queue exceeds an original high-depth-alarm setting, wherein the depth level is a measure of data within the queue, wherein the queue is a messaging-middleware queue, and wherein the information originates from an event message, wherein the high-depth-alarm setting is a first percentage of a maximum depth;
increasing the maximum depth of the queue from an original maximum setting to an updated maximum setting that is larger than the original maximum setting, thereby
(1) allowing the queue to receive additional messages while a cause of a high-depth condition receives user attention, and
(2) preventing disruption to a process of transferring messages to the queue;
disabling a low-depth alarm for the queue that generates an alarm when the depth level crosses from above a low-depth-alarm setting to below the low-depth-alarm setting, wherein the low-depth alarm for the queue, wherein the low-depth-alarm setting is a second percentage of the maximum depth; and
storing an indication that the maximum depth of the queue was increased, such that the maximum depth may be reset upon determining that the cause of the high-depth condition is resolved.
9. The media of claim 8 , wherein the method further comprises determining that a current depth level for the queue is less than the original high-depth-alarm setting; and
incident to said determining,
(1) changing the maximum depth from the updated maximum setting to the original maximum setting, and
(2) enabling the low-depth alarm for the queue.
10. The media of claim 8 , wherein said storing comprises:
generating an entry in a data store that includes at least queue identification information, the original maximum setting, and a reset-request indication field that includes a first indication that indicates the maximum depth was increased and not reset.
11. The media of claim 8 , wherein the event message is generated by a queue manager.
12. The media of claim 8 , wherein the event message is generated by a queue monitoring component that generates alarm messages.
13. One or more computer-readable media having computer-executable instructions embodied thereon for performing a method of automatically managing alarms in an environment where a period of time could pass before the cause of the alarm is addressed, the method comprising;
receiving information indicating that a depth level of a queue exceeds an original high-depth-alarm setting, wherein the depth level is a measure of data within the queue, wherein the queue is a messaging-middleware queue, and wherein the high-depth-alarm setting is a first percentage of a maximum depth;
increasing the maximum depth of the queue from an original maximum setting to an updated maximum setting that is larger than the original maximum setting, thereby
(1) allowing the queue to receive additional messages while a cause of a high-depth condition receives user attention, and
(2) preventing disruption to a process of transferring messages to the queue;
disabling a low-depth alarm for the queue that generates an alarm when the depth level crosses from above a low-depth-alarm setting to below the low-depth-alarm setting, wherein the low-depth alarm for the queue, wherein the low-depth-alarm setting is a second percentage of the maximum depth; and
storing an indication that the maximum depth of the queue was increased, such that the maximum depth may be reset upon determining that the cause of the high-depth condition is resolved, wherein the indication is an entry in a data store that includes at least queue identification information, the original maximum setting, and a reset-request indication field that includes a first indication that indicates the maximum depth was increased and not reset.
14. The media of claim 13 , wherein the method further comprises determining that a current depth level for the queue is less than the original high-depth-alarm setting; and
incident to said determining,
(1) changing the maximum depth from the updated maximum setting to the original maximum setting,
(2) enabling the low-depth alarm for the queue, and
(3) updating the reset-request indication field to include a second indication that indicates the maximum depth was reset to the original maximum depth setting.
15. The media of claim 13 , wherein the information originates from an event message.
16. The media of claim 15 , wherein the event message is generated by a queue manager.
17. The media of claim 16 , wherein the event message is generated by a queue monitoring component that generates alarm messages.