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#4242366 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4242366 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
