JMS – Handling an Error

In a previous post, I’d reluctantly had to post an warts-an-all solution to handling error conditions in JMS. This involved a sleep to hold up the thread from processing any further messages. I’ve since spent a couple more days reading around the solution – and have a nicer alternative working. I’m not certain I should be doing this solution though, but its expressing the exact behaviour I’m after, and doesn’t appear to have caused any issues in the limited testing I’ve performed.

To recap, the behaviour I’m after is to stop processing messages when an error is encountered. In an ideal world, the current message would be placed back on the queue for later processing. I’m generally expecting the error encountered to be something like a database connection to not be available or similar. So hence would like to save the message, manually check what the issue was, resolve and then start the message processing again.

I’m developing the onMessage() method from the previous post.

During my time reading over the past couple of days I became more familar with the command line interface to GlassFish – asadmin (on a windows system found under C:\Program Files\sges-v3\glassfish\bin – if you’ve got a default installation). This command accepts a ‘disable’ option and allows you to specify the Application to disable. Its also got a whole host of other commands which could prove of interest later, but not for now.

Instead of sleeping in my Exception handler, I’m now calling Runtime.getRuntime().exec() and passing it the command to ‘asadmin disable MyMessageHandler’ to disable the app. Provided this happens after the mdc.setRollbackOnly(), all my requirements are fulfilled – the original message is placed back into the queue and the application for processing messages is stopped.

The source code is along these lines:

} catch (JMSException e) {
   System.out.println("Handling JMSException. Setting rollback only");
   try {
      String[] commands = { "\"c:/program files/sges-v3/glassfish/bin/asadmin.bat\"", "disable", "MessageExampleEE" };
   } catch (IOException ex) {
      Logger.getLogger(MessageBean.class.getName()).log(Level.SEVERE, null, ex);

I’m not 100% comfortable with making this call from within the application, and I’m slightly concerrned that I may be breaking some kind of EJB specification, but having done a brief search can’t find anything jumping out at me. Also testing seems to have gone well at the moment. However, if anyone can tell me that I shouldn’t do this, I’m happy, as ever, to be guided! I’ll continue testing and reading over the next couple of days to see if I can find out more for myself.


2 thoughts on “JMS – Handling an Error

  1. Pingback: Java Message Queuing (Continued) « Gregor Bowie's Blog

  2. Apparently EJB specs mention that you should not spawn threads or processes from an EJB.. But generally application servers do allow you to get away with it..

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s