Hello Timfox With 'workers' i guess i mean consumers. In the jbos.xml i have a config like this: <invoker-proxy-binding> --bla bla 20 20 /-bla bla meaning i want 20 concurrent consumers (the logging calls them workers) to work parallel to pick up the messages that are sent to the queue. A nice feature, but during that process consumers get lazy and do not respond anymore :(. So, with JBossMQ the only solution is to restart JBoss after about 24 hours. I presume that any other solution, ie JBoss Messaging, could have the same problems so a nice feature would be if it would have the ability to recover from dying consumers. If not, a reset of the messaging system would hlp a lot because other services would be uneffected by a restart. Another problem with JBossMQ (most probably) is that JBoss JCA connection pool is very itchy about not closing database connections. So, when a consumer stalls, it might keep the connections open indefinitly and this will lead to terrible other problems. Just do a search on the forums and you will see that a lot of people who switch to JBoss experience significant problems with JCA. And in my configuration you see a lot of dead database connections combined with a decrease in MQ activity. So, to solve my problem i see a few possible solutions: 1. improve the code that is executed in the consumer (because the consumer hangs because my code within it hangs) 2. get a MQ system that have some managing capability (to cover up for 1.) 3. drop JBoss JCA, it is simplly too itchy about connection closing (but this is a different story) So, basically i my situation i would like to configure the following: "Dear messaging system. You have to work through thousands of messages per day. I would like you to process them swiftly, and with accuracy i could expect from a computer program. But, every now and then you will get an evil message that might take too much of your attention. Please discard these messages if you spend more then 10 minutes of your time (or put them in a evil messages group where a few dedicated consumers handle these nasty cases)." And if a tsunami of evil messages arrive at your get i understand, so no heart feelings when i want to restart you without bothering other processes that are running in the application server! FYI, a single message in our application will lead to several hundreds http connections with other servers, serveral thousand database requests, a couple of external webservices (AXIS, JBoss WS... cool features!) etc. So, a lot of situations where things can stall or go wrong. To get a feeling, if the concurrent cosumers are set to 20++, JBoss will die within the hour (only option "kill -9 PID"). And one other thing. We have a couple of message queues. Some can be considered 'bulk queues', but others are processing financial transactions, so i would wish to discriminate them (the pigs queue is more equal then others). In a nutshell: - messaging managability - restart, preferably on queue level - discriminating queues - recovering of dead consumers, or... - regrouping slow/fast messages, so the bulk will be processed in time View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978301#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...