Sprint Communications Comapny L.p.

Sprint Communication Cômpany L.p.

Mark D Leonard

Terriss L Ford

Brian John Washburn

Kailash Krishnamurthy

Jennifer Mae Carlton

An endpoint monitoring for a machine to machine (M2M) messaging framework system is disclosed. The system comprises a monitoring server and a monitoring application stored in a memory of the monitoring server. When executed by a processor of the monitoring server, the monitoring application queries a plurality of brokers that are communicatively coupled with a plurality of message queue telemetry transport (MQTT) clients for data regarding the rate of disconnections that occur between the brokers and the MQTT clients. The monitoring application compares the data received from the brokers and compares the rate of disconnections to data in an information data store. If a high rate of disconnections is discovered in at least one of the broker to MQTT client connections, the monitoring application takes action, for example reboots an MQTT client and/or sends a notification message.

Endpoint monitoring for a messaging framework

A method of trace route auditing and alarming for message queuing middleware. The method comprises transmitting, by a server computer in the message queuing middleware system that implements message queuing services, a trace route message requesting an activity report to a partner computer, receiving, by the server computer, the activity report comprising message activity information from the partner computer, and comparing, by an application executing on the server computer, the most recent message activity information with message activity records to detect changes in message activity, wherein the application is stored in a memory of a computer and is executed by a processor of the computer. The method further comprises responsive to message activity changes being detected, determining by the application a cause of activity change based on the comparison.

Trace route audit and alarming

Methods, systems, and media are provided for automatically determining a preferred queue size for an individual queue based on message traffic. Embodiments include referencing a plurality of queue data sets for one queue. One or more high-activity queue data sets are identified as having a large number of messages compared to other queue data sets in the plurality. Thereafter, a target size for a queue is determined based on an average message size generated using one or more of the high-activity queue data sets. The current size of the queue is adjusted to reflect the target size. In further aspects, the queue data sets may be collected over time intervals that are dynamically modified based on message traffic.

Automatic queue size determination and tuning

A system is provided for monitoring message queue data. The system includes a computer readable storage medium comprising a message counter component stored as a set of computer instructions executable by a processor. The counter component detects the outflow of messages comprising at least expired messages and at least received messages out of a message queue. The counter component differentiates the outflow of expired messages from the outflow of received messages. The counter component collects message queue data, wherein collecting the message queue data comprises at least counting the outflow quantity of expired messages or at least counting the outflow quantity of received messages. The counter component calculates at least one of a plurality of message counting metrics based on at least the message queue data collected over a period of time. The counter component transmits at least one of the message counting metrics to a message interface.

System and method of calculating and reporting of messages expiring from a queue

A method, system, and computer-readable media for automatically detecting an abnormal data transfer rate in a channel instance. The method includes determining a normal data transfer rate for a particular channel instance and then monitoring data transfer rates for a channel instance. Corrective action may be taken when the data transfer rate in a channel instances deviates more than a threshold amount from the normal rate.

Detecting upset conditions in channel instances

A dynamic telemetry client message routing system is provided. The system comprises a provisioning application stored in a memory of a computer system that, when executed by the processor of the computer system, receives a request from a telemetry client to register for message routing services; the request comprising a client identity. The provisioning application creates an entry in a data store associating the client identity with a broker group identity and a queue manager alias and a time to live value. The provisioning application sends a request to a route builder to configure the queue manager alias into the broker group. The route builder sends a message to the broker group to configure the queue manager alias. The message broker receives a request to send a message to the telemetry client and transmits the message and the queue manager alias of the broker group accessed from the data store.

Dynamic telemetry client message routing

A system comprises a component which receives an initial status message, from a primary queue manager, comprising a rate of data messages moving into a primary queue. The component detects that a primary queue rate is below a predetermined range based on the received initial status message. The component increases the weight of the primary queue in response to detecting that the primary queue rate provided by the initial status message is below the predetermined range. The component receives a subsequent status message, from the primary queue manager, comprising the rate of data messages moving into the primary queue. The component detects that the primary queue has a rate below the predetermined range based on the received subsequent status message. The component activates a secondary queue in response to detecting that the primary queue rate provided by the subsequent status message is below the predetermined range.

System and method of maintaining an enqueue rate of data messages into a set of queues

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.

Detecting upset conditions in application instances

A method, system, and medium are provided for automatically determining a preferred queue size for an individual queue based on message traffic. The method includes referencing a plurality of queue data sets corresponding to messages associated with a queue within a collection time period. A queue data set associated with a largest number of messages in the queue is identified from within the plurality of queue data sets and, thereafter, a target-queue size is determined using queue data associated with the largest number of messages in the queue. In further aspects, the individual queue can be automatically tuned based on the target-queue size.

A method, system, and medium are provided for monitoring channels running on a queue manager. Both the total number of channel instances and instances of each named channel running on a queue manager may be monitored over time. The number of channels running overtime may be compared to the total number of channels allocated to the queue manager. The allocation may be adjusted when the comparison indicates too few or too many channels are allocated to the queue manager. Individual channel instances may also be evaluated to optimize allocation at a more granular level.

Channel optimization in a messaging-middleware environment

Systems and methods for retrieving service request messages stored in a messaging queue and received by a queue in real-time. The service request messages are retrieved using a plurality of threads that comprise at least one retrieval criteria. Service request messages may be retrieved from the message queue or retrieved as they are received by the message queue in real-time using criteria in addition to or instead of the arrival time of the service request message which may also be referred to as the put-time. Service request messages may be requested and retrieved in an iterative process wherein multiple threads execute consecutively, concurrently, or a combination of both, in order to retrieve service request messages requested by an application.

Retrieving service request messages from a message queue maintained by a messaging middleware tool based on the origination time of the service request message

A method, system, and medium are provided for monitoring the data volume in a file log associated with a program (e.g., a queue manager) in a failover computing environment. A failover computing environment includes pairs of programs capable of performing the same functions. One program in the pair is the primary program and the other is the backup program. Only one of the two programs is active at any given time. Embodiments of the present invention may identify the file directory for each program installed on a computing device. The location of each file log may be determined by accessing a core-configuration file in the file directory associated with the program. The program only has access to the core-configuration file when the program is active. Once the file log is located, the file usage may be ascertained and compared with a threshold usage.

Message-recovery file log locating and monitoring

A transaction server. The transaction server comprises a processor, a non-transitory memory, and an application stored in the non-transitory memory. When executed by the processor, the application transmits a plurality of transaction requests to at least one backend server, where the backend server performs processing on the transaction, determines that a transaction request timeout occurs when a transaction response has not been received from the at least one backend server within a timeout time period after transmitting the associated transaction request, and adjusts the timeout time period based on the transaction request timeouts without restarting.

Application transaction wait time dynamic adjustment

A message queuing system implemented by at least one computer. The system comprises a performance queue to keep event status related to performance of non-performance queues, threads, which are sequences of programmed instructions, launched by the queue managers to transmit and receive messages over connections between individual queues, and an external monitoring application or a monitoring application within a queue manager. The monitoring application monitors threads, channels, and events in the message queuing system, polls the performance queue periodically and counts the number of threads in the case of the external monitoring application, directly gathers current event information in the case of the monitoring application within the queue manager, determines whether both the thread/threads and channel have failed when all threads of an application are missing, and restarts channels that failed after determining that both channels and all threads have failed.

Messaging middleware processing thread count based events

A computer implemented method is provided for message queue failure recovery. The method comprises detecting a failure in a message queue or a queue manager for the message queue, detecting a current status of each of the message queue and the queue manager, examining a maintained active log for the message queue and a message recovery log, examining usage of system resources associated with the message queue and the queue manager, and executing one of a plurality of failure recovery procedures based on the current status of the message queue and the queue manager, the active log, the message recovery log, and the usage of the system resources.

Growing community of inventors

Olathe, KS, United States of America

Mark D Leonard