BTW,AUTO_ACKNOWLEDGE can not guarantee once and only once semantic since the ack is sent async. You can image such a case when your consumer has succeeded in processing a message while the consumer application is crashed before the ack is sent, you will receive that message again if your applications get restarted. Seems what you really want to solve is to distribute real task messages evenly between consumers. As default a consumer has a prefetch to allow broker to push messages to it in batch manner, if a consumer is slow to process message then many pending messages will be accumulated and other consumers may suffer starvation.In this case those real tasks wont get executed in time. You can just use pull mechanism for your consumers so that your consumer can pull real task message from broker one by one. Fast consumers can have a chance to pull more messages than slow consumers. If consumers still can not process real tasks in time, increase consumers or tune performance for consumers.
2014-02-24 19:07 GMT+08:00 Li Li <fancye...@gmail.com>: > I've read the jms specification and questions by google such as > > http://stackoverflow.com/questions/2991412/anyone-know-exactly-which-jms-messages-will-be-redelivered-in-client-acknowledge > . But I still confused about it. > Another question is: how can a consumer tell the broker to > redelevery a message to other consumers(maybe again to this consumer) > e.g. we have some real time tasks and here is code: > class MyConsumer implements MessageListener{ > > public void onMessage(Message msg) { > doPhrase1(); > if(leftTime < avgTime1){ > //Tell broker I can't finish it in time, > //you should redelevery to other consumers > //do some cleanup job > } > doPhrase2(); > if(leftTime < avgTime1){ > //Tell broker I can't finish it in time, > //you should redelevery to other consumers > //do some cleanup job > } > doPhrase3(); > } >
