The threads are coming from my client application - there is a thread per http request and
at the end of the request it calls send(). Hundreds of these threads are created every
minute so if the call to send() blocks then it doesn't take long for the blocking to
overwhelm the VM. I guess I could re-architect my application to put the messages in a
queue and have one thread pull the messages off and send them, this just feels a bit like
I'm implementing something which could (should?) be in the messaging client.
As for the ExceptionListener solution, I thought about this too. I have JBM setup to
auto-reconnect so I don't actually get an exception when the server goes down (I just
see some warning messages in the logs). From what I can tell the sender queues up the
messages in the background. When the server comes back, only then does my
ExceptionListener callback get called, at which point I redo the JNDI lookup and recreate
the connections and sessions etc. This works well. I think if I set JBM not to
auto-connect then the ExceptionListener callback is called right away when the server goes
down, but then I have to do my own reconnect logic. I'm happy with this
ExceptionListener logic, it would just be nice to be able to throw messages away instead
of blocking, but maybe I should code this up myself.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4242366#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...