JMS message preserve when DB down

Question

Application Overview :

In my application we use to receive 60000 messages every day. It is using 11 MDB and MessageListener to subscribe the messages from different OMB queues and process it. Using weblogic server and JAP. We have total 32 instance for each MDB, because we have 8 different node each node's max-beans-in-free-pool is 4.

Current Problem :

When DB down, catch it in exception and rollback the transaction context so message will put back to queue. We checking if JMSXDeliveryCount is less then 100 it will retry else it will drop the message and send the email with message reference.

Problem : Message is getting lose, 100 time retry reach with in few secs. but DB may up after 2 hours.

Proposed approach :

Check database connectivity prior to processing a message, if DB connectivity isssue – sleep the thread for 5mins after repoll to check the connection. In this case each MDB can hold 32 message (Tread) in application level remaining message will be in queue. We have 11 MDB so possible of (11*32) thread will be sleep in application level.

I felt its bad to check DB connection for all message at initial level and holding 352 message (controlling 352 thread, possible of weblogic crash) in application level till DB up.

Any better approach to handle this issue in MDB level or weblogic level ?

Answer 1

Container managed transaction – instead of handling the thread / message retry through code, container will handle it.

Container will retry the message based on MDB configurations mentioned below.

i.e under weblogic-ejb-jar.xml: message-driven-descriptor

        <init-suspend-seconds>2</init-suspend-seconds> 

Starts with 2 seconds retry. Retry interval seconds doubled every time until max retry of 300 seconds reached. i.e 2, 4, 8 … 300

        <max-suspend-seconds>300</max-suspend-seconds> 

Once 300 seconds reached, containers keeps retrying every 300 seconds until the cause of the failure is resolved. Once resolved the issue container resumes the normal processing of MDB instance.

<message-driven-descriptor>
<pool>
    <max-beans-in-free-pool>4</max-beans-in-free-pool>
    <initial-beans-in-free-pool>1</initial-beans-in-free-pool>
</pool>
<destination-jndi-name>XXX_FOREIGN_DEST_LOCAL@env_name@
</destination-jndi-name>
<connection-factory-jndi-name>XXX_FOREIGN_QCF_LOCAL@env_name@
</connection-factory-jndi-name>
<init-suspend-seconds>2</init-suspend-seconds>
<max-suspend-seconds>300</max-suspend-seconds>
</message-driven-descriptor>