Win a copy of liveProject: Protecting User Data with Spring Security and OAuth2 this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • paul wheaton
  • Devaka Cooray
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Piet Souris
  • salvin francis
  • Mikalai Zaikin
  • Himai Minh

Strange behaviour of MDB and EJB

Ranch Hand
Posts: 257
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.

Here is the code of MDB

Here is the code of Stateless Session Bean

Ranch Hand
Posts: 491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
and this Programming WebLogic JMS which is your case ( I have not read it)

Go luck to you.

Edit: forgot to include Experiment code + log

Consider Paul's rocket mass heater.
    Bookmark Topic Watch Topic
  • New Topic