[andreas_back]

Hello HonetQ-Team,

we had a closer look into this issue.

1.     From the first view it was hard for us to distinguish this from a real showstopper for using the combination

*     MDB's

*     HornetQ

*     and JBoss 5.1.0.GA

Therefore it would be great if a member of the HornetQ-Team could have a look at it,

JMSXDeliveryCount: 1
getJMSRedelivered(): false

is observed for all the repeated invocations of the same Message (identified by message.getJMSMessageID()) in the onMessage method.

This may be a discrepancy to 3.4.7 in the JMS specification:

"In general, a provider must set the JMSRedelivered message header field of a message whenever it is redelivering a message", see page 33.

A test case has already been posted by jaikiran pai at 17.04.2010 11:26.

2.     Since we are migrating an existing application we had a look at the frequency of the rollback in the our MDB's.

We would not call it a workaround but setting

          redelivery-delay

to an adequate value could at least reduce the number of logging statements (if one uses a mail-appender for them also the number of mails that are emitted per time period).

If the redelivery-delay is high enough then messages that have caused a RuntimeException in the onMessage method could be deleted manually from the queue.

With best regards,

Andreas

[jaikiran]

Earlier, in this thread I said:

I believe this was fixed in JBoss AS 6.0.0.M3. Which version of JBoss AS  are you using?

I was wrong about that. I just retested this against AS trunk and this is still an open issue. The issue is being tracked in this JIRA https://jira.jboss.org/browse/JBAS-7950

[andreas_back]

Hello Jaikiran,

thank you very much for your quick reaction to the posting!

Now the bug has at least one vote. (I would not say the the bug is totally unimportant ...)

With best regards,

Andreas

[andreas_back]

Hello Jaikiran,

1.     in search for a workaround to prevent infinite redeliveries in the case of a runtime exception within a message driven bean we experimented with

*     QueueSender.setTimeToLive when sending the message and

*     the redelivery-delay that is set for the queue.

We found the following possible workaround:

If the redeliverry-delay is greater than the QueueSender.setTimeToLive then the message is transferred to the ExpiryQueue.

The message is visible in the ExpiryQueue (via the JMX-console) after the redelivery-delay is over.

Since we set max-delivery-attempts = 1 (as a wanted characteristic of the application)

*     to set the QueueSender.setTimeToLive large enough

*     and to set redelivery-delay > QueueSender.setTimeToLive

could be workaround for us.

2.     The bug has been reported under https://jira.jboss.org/browse/JBAS-7950 and Tim assumed in April:

>    I suspect HornetQ isn't actually redelivering this message - it's getting redelivered somehow in the JCA / MDB layer

This could be true, but the testings with the parameters under 1. show that HornetQ has at least some influence on the delivery. Therefore a look of someone of the HornetQ - Team on it might be senseful?

With best regards,

Andreas

[timfox]

andreas_back wrote:

2.     The bug has been reported under https://jira.jboss.org/browse/JBAS-7950 and Tim assumed in April:

I wasn't aware of this bug until yesterday since it had been posted against the JBoss-AS project not the HornetQ project.

If it's a problem in HQ not the JBoss AS implementation it should be posted against HornetQ JIRA or we won't know about it!

[jaikiran]

Tim Fox wrote:

andreas_back wrote:

2.     The bug has been reported under https://jira.jboss.org/browse/JBAS-7950 and Tim assumed in April:

I wasn't aware of this bug until yesterday since it had been posted against the JBoss-AS project not the HornetQ project.

If it's a problem in HQ not the JBoss AS implementation it should be posted against HornetQ JIRA or we won't know about it!

I'm not really sure whether the bug is in HornetQ or HornetQ-JBossAS integration. Andy had investigated this issue sometime back and I don't know whether he had a chance to figure out what the problem was. If Andy or anyone from HornetQ team has a chance to confirm that it's a HornetQ issue, then let me know - I'll create one in HornetQ JIRA and mark that as a dependency for JBAS-7950.

[timfox]

Can someone please provide a simple MDB I can run and HornetQ server config in order to replicate this? (Please don't point me to the AS test suite).

So far I cannot replicate this with pure HornetQ.

[jaikiran]

Tim Fox wrote:

Can someone please provide a simple MDB I can run and HornetQ server config in order to replicate this? (Please don't point me to the AS test suite).

Sure. I'll create a simple one.

[jaikiran]

The JIRA https://jira.jboss.org/browse/JBAS-7950 has been updated with a simple application which reproduces this issue. The steps to reproduce are also mentioned in the JIRA.

[timfox]

Thanks Jaikiran, will take a look.