This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have an MDB that calls a Stateless Session bean , the Stateless session bean has Transaction attribute of Not Supported. The onMessage() of the MDB calls Stateless SB method that takes lot of time to perform. There are no errors thrown in the MDB and Session Bean but the same message gets redelivered to the Queue and is relayed back to the MDB. I did a small POC and I am able to replicate the issue. But I don't have any clue how to fix this issue.
If the MDB is Container type, should it not has the server/EJB container transaction timeout?
Is @TransactionTimeoutSeconds(200) a weblogic way to override the server side?
Basically, I did a simple experiment like your with trial RAD 7: MDB call SLB that has Thread.sleep(200000) in it;
and observed in log (I have log, check your server log). I noticed the message was redelivered 5 times. (because it was configured 5 times for re-delivery on RAD server side)
BUT then if you restart the EJB Listerner again, JMS Provider will continue to deliver that same message.
Why? (see the articles/links I mentioned below.)
When I set Thread.sleep(120000) in SLSB, it was re-delivered only 2 times and that'all.
When I set Thread.sleep(110000) in SLSB, there is NO issue.
Unless, I misread the log, here is what I understand:
1. JMS Provider ----->jms message----->EJB container/AppSrv---jms message + timeout period----> MDB -----> SESSION BEAN (can take whatever it takes)
2. There is a transaction time out between EJB container/server and the MDB (Here is the issue. The default value for MDB on RAD is 120s)
3. After timeout occured, EJBcontainer give back the same message to JMS Provider.
4. As long as JMS Provider has message it deliver to EJB container who in turn give it to MDB
and the loop continue as long as N times ( 5 times in my test because it was configured 5)
Unless instructed otherwise -configuration setting- , JMS Provider will continue to deliver that same message
to EJB container.
Now try : 1. increase transaction time out at EJB container/server level OR at specific MDB level (Bean level)
what is the max then? depends on how long your SLSB take? play with these values
2. OR review the logic in SLSB or re-design the flow to decrease the time it take to finish.
3. OR do more re-search in term of all the configuration settings at Queue/JMS Provider and/or EJB container and/or MDB
to see which value can influence the outcome.
4. OR there is more for which I do not know...
BTW: while doing the experiment, I found an article about this issue but it's for IBM websphere
but the key concept should be similar in your web logic server/JMS provider. Check if it has these settings and play with it.
How WebSphere Application Server V6 handles poison messages