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
I'd keep the servlet with JMS, and I'd not do the polling --- I'd just do logic like:
(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.
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
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: