Optimizing A Message-Driven Bean Lifecycle Based On A Systemic Feedback Mechanism
Publication Date: 2015-Jan-20
The IP.com Prior Art Database
A method and system is disclosed for optimizing a Message-Driven Bean Lifecycle based on a systemic feedback mechanism by taking into consideration various factors such as, but not limited to, Java Message Service (JMS) resource adapter thread pool, Java Virtual Machine (JVM) heap, message durability and other Quality of Service (QoS) features.
Page 01 of 2
Optimizing A Message - Mechanism
A Message-driven bean (MDB) is an enterprise bean that allows Java EE applications to process messages asynchronously. MDBs typically listen to queues or topics and process one or more incoming messages. When a message arrives on a topic or queue (generically referred to as a destination), the onMessage method of the MDB is called. The onMessage method, then, handles the message based on business logic coded within it. For example, the onMessage method can invoke a session bean, or may directly interact with a database. However, MDBs are created within an application server without taking into account the queue/topic for which the messages are being processed. More specifically, a queue depth (number of messages on the queue) is not taken into account by the MDBs while processing the queue.
Disclosed is a method and system for optimizing an MDB lifecycle by taking into consideration various factors such as, but not limited to, Java Message Service (JMS) resource adapter thread pool, Java Virtual Machine (JVM) heap, message durability and other Quality of Service (QoS) features.
In an embodiment of the present invention, the method and system modifies an application server in order to be able to analyze queue depth in order to determine a number of MDBs to be made available in a method-ready pool. The application server
will also analyze how long an MDB typically takes to process a message in its determination of whether to make more MDBs available or whether to cut down the number of MDBs that are instantiated (i.e., in the 'Does Not Exist State').
The disclosed method and system utilizes a thread to analyze a destination that a given MDB is configured to listen to. In particular, the method and system constantly analyzes the destination depth of the destination. The method and system, then, establishes a policy at a cluster level stating that for every 100 messages on the queue, the cluster should have at least 1 MDB instance created. Therefore, based on the policy, for a queue depth of 5000 messages, the method and system creates 50 MDBs across the cluster.
The method and system also takes into account factors such as, but not limited to, an average time taken for an MDB to process a message off of a queue, a measure of the memory usage and its impact on JVM...