AbstractJMSHibernateSearchController should handle RuntimeExceptions

Description

onMessage() of AbstractJMSHibernateSearchController could throw a RuntimeException in its try clause which would then propagated to the caller of the method. This is wrong from a JMS spec perspective which says in 8.7. Receiving messages asynchronously:

It is possible for a listener to throw a RuntimeException; however, this is considered a client programming error. Well behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific ‘unprocessable message’ destination.

The result of a listener throwing a RuntimeException depends on the session’s acknowledgment mode.
...

The question is what the best approach is to handle this? Potentially we are going to loose a whole bunch of index updated. What else except logging them can we do?

Environment

None

Activity

Show:
Emmanuel Bernard
September 17, 2014, 8:53 AM

A MDB throwing a runtime exception will rollback the transaction and
put back the message in the queue. The message will be retried a few
times before going in a problem queue of sort (that is configuration and
vendor specific).

It was not the intent of my code to support subclasses that are not MDB.

Hardy Ferentschik
September 26, 2014, 7:17 PM

It was not the intent of my code to support subclasses that are not MDB.

Maybe that was the case initially and I seem to remember the base class we provided was a MDB. However, AbstractJMSHibernateSearchController does not make any assumptions about the listener and it does not even mention MDB. If nothing else the docs should discuss the problematic around {{RuntimeException}}s.

Assignee

Unassigned

Reporter

Hardy Ferentschik

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Affects versions

Priority

Minor
Configure