Http accepter or Message Queue which is better

Posted by smahanta on 04-Dec-2009 23:29

I have a servlet based web application which handles form submission & after applyling some xslt transformation sends an xml to a message queue which is a part of a distributed sonic application. It uses sonic JMS api for sending the message..Currently I have written a context listener which at the web application start-up creates a jms connection with the message queue.Problem is from time to time we have to bring down the sonic application. Now the jms connection becomes stale & the web application cannot pump message without restarting the server in which the web application is hosted. I can write such code which when faced with jms exception will try to re-establish the jms connection.But I do not want to write such code because it will be a thread which will keep polling & will strain system resource.

It is possible for me to expose that message queue as an http acceptor. This will free my code of any sonic jms api reference

If my web application sends the processed message to an url then I can get rid of the tight coupling between web application & sonic. But will there be any performance penalty?

--Subhendu

Technology Partner - Forum

All Replies

Posted by Bill Wood on 05-Dec-2009 10:39

I'd keep the servlet with JMS, and I'd not do the polling --- I'd just do logic like:

  •   check if connection is active
  • if not, create one
  • use it.

(the connection would have an exception listener that when fired sets active=false).

This way you wouldn't poll.

If all you are doing, however, is sending messages to Sonic (with no replies back) the HTTP acceptor would be fine.

If the Sonic service was down, you'd still have to handle the HTTP 404 response.

Posted by smahanta on 11-Dec-2009 21:13

I have used the ExceptionListener as suggested.

Currently I am using single connection to the sonic queue. Is there a way to have multiple load-balanced connections to the same queue to improve performance?

--subhendu

Posted by Bill Wood on 12-Dec-2009 08:27

You can easily have multiple connections writing to the same queue.  Similarly, you can have many connections reading from the queue.  I am not sure either would improve performance.

If you use a CLUSTER, and have a CLUSTERED queue, then if you have some senders on one broker and some on others, and some receivers on some brokers and some on the others, then the paired sender/recievers on each broker will tend to read/write to each other.  I think that might be what your question is.

The best way to get performance is to:

  • test on a system(s) that match your prodcution hardware
  • use fast disks when there is any persistence or durability

This thread is closed