Message Bean and JMS - messages not disappearing from queue

[Chris]

Hi,

I've written a message bean that monitors a JMS queue and successfully runs.
I made changes to the onMessage method to include a new piece of code which
due to another error threw an exception. When I wasn't catching this
exception the onMessage method didn't complete and so the message wasn't
removed from the queue. As a result there were endless calls to onMesssage.

Why did this mean the message was left on the queue? Is there any way to
force the message to be removed?

When I swallowed the exception the method completed and the bean was
removed. However I then introduced a new piece of code (call to a stateless
session bean) which threw an exception. However this time while attempting
to swallow that exception in it's originating class (I was catching
Throwable) the bean wasn't removed and again there were endless calls to
onMessage.

Any ideas why this could be. I thought by catching Throwable and not
propagating the exception there would be no reason for the onMessage method
to not complete.

Thanks for any suggestions

Chris

 

[Chris]

I've written a message bean that monitors a JMS queue and successfully
runs.

I made changes to the onMessage method to include a new piece of code which
due to another error threw an exception. When I wasn't catching this
exception the onMessage method didn't complete and so the message wasn't
removed from the queue. As a result there were endless calls to onMesssage.

Why did this mean the message was left on the queue? Is there any way to
force the message to be removed?

When I swallowed the exception the method completed and the bean was
removed. However I then introduced a new piece of code (call to a stateless
session bean) which threw an exception. However this time while attempting
to swallow that exception in it's originating class (I was catching
Throwable) the bean wasn't removed and again there were endless calls to
onMessage.

Any ideas why this could be. I thought by catching Throwable and not
propagating the exception there would be no reason for the onMessage method
to not complete.

I found a solution now in case anyone's interested - I started my call to
the session bean in a new thread

It seemed the time it was taking to call the session bean interrupted the
onMessage method

 

[Raymond DeCampo]

I found a solution now in case anyone's interested - I started my call to
the session bean in a new thread

It seemed the time it was taking to call the session bean interrupted the
onMessage method

Am I to understand that you started a new thread in your MDB onMessage()
method? This is a violation of the EJB specification which prohibits
EJBs from creating threads. I'd encourage you to look for a better
solution as your current one may be fragile.

HTH,
Ray

 

[Chris]

Am I to understand that you started a new thread in your MDB onMessage()
method? This is a violation of the EJB specification which prohibits
EJBs from creating threads. I'd encourage you to look for a better
solution as your current one may be fragile.

Yeah good point, threads in EJBs is a big no no.

I found a better solution. The problem was due to a deep level exception
thrown by a database driver which wasn't being propagated up the call stack.
It was however forcing the transaction on the message bean to roll back. I
therefore fixed this by making my bean non-transactional.

Also changing the redelivery tries from infinite to 0 on the JMS queue
stopped the continuous redelivery of the message.