JMS queue consumer challenge

Question

Hi there,
          I have met a pretty challenging problem in JMS queue consumer and
          would like to know if any JMS lovers in the group know about it.
          We have queue receiver listening on queue which contains a number of
          mugs.
          Once a msg is received (onMessage returns), the msg is handed over to
          a worker thread from a thread pool.
          Essentially there are two parts of the problem:
          1. We want kind of flow control - only x number of msg can be
          processed at a given time. This can be resolved by using semaphore.
          However, there might be better solution out there. Anyhow, this is
          less an issue than the second part -
          2. As we know client_acknowledge happens at the session level:
          Acknowledging a consumed message automatically acknowledges the
          receipt of all messages that have been consumed by its session. For
          example, if a message consumer consumes ten messages and then
          acknowledges the fifth message delivered, all ten messages are
          acknowledged. 
          -- this is the problem -- we want to acknowledge each msg
          individually so that only the processed msg is acknowledged although
          there are x number of msg being retrieved. By doing that we won't lost
          any msg in case the JMS client crashes.
          It is a challenge, isn't it? Might well not be one for you, if you
          know the trick. If you do, could you share with us? Thanks a lot.
          Mike
          

Answer 1

Just to be clear, I favor (2), where each worker thread has its own session and
          consumer.
          This naturally throttles, as there are only as many outstanding messages as
          worker-threads.
          BTW, be aware that it is against spec, and dangerous, to call acknowledge()
          outside of
          onMessage() - as this multi-threads the Session and Session's are not thread
          safe.
          Tom
          Tom Barnes wrote:
          > Actually you both are correct. The ack behavior is configurable on the
          > connection factory via the "AcknowledgePolicy", where the default is
          > what the spec requires (ack-all). Prior to 6.1
          > the behavior was what one would expect (ack-before).
          >
          > As for how to solve the problem at hand. I can think of three approaches:
          >
          > (1) use the current async consumer but set the ack-policy
          > to ack-before, and defer acknowledging a msg until all msgs before
          > it have finished their processing
          >
          > (2) use multiple synchronous consumers, one consumer per defered msg
          >
          > (3) use a single synchronous consumer, but dequeue transactionally,
          > one transaction per msg. suspend the transaction, then have
          > the worker thread resume the transaction once it finishes processing
          > the message and call commit. (Take care that the default
          > tran timeout is 30 seconds.)
          >
          > Shean-Guang Chang wrote:
          >
          > > Just to correct one assumption. Ack the fifth message will not ack message
          > > received after that (e.g. message 6, 7, 8, etc...). At least not WLS JMS.
          > > If this is not true for you please give details of your client code and
          > > version of WLS JMS you have. Thanks!
          > >
          > > "Mike" <[email protected]> wrote in message
          > > news:[email protected]...
          > > > Hi there,
          > > >
          > > > I have met a pretty challenging problem in JMS queue consumer and
          > > > would like to know if any JMS lovers in the group know about it.
          > > >
          > > > We have queue receiver listening on queue which contains a number of
          > > > mugs.
          > > > Once a msg is received (onMessage returns), the msg is handed over to
          > > > a worker thread from a thread pool.
          > > >
          > > > Essentially there are two parts of the problem:
          > > >
          > > > 1. We want kind of flow control - only x number of msg can be
          > > > processed at a given time. This can be resolved by using semaphore.
          > > > However, there might be better solution out there. Anyhow, this is
          > > > less an issue than the second part -
          > > >
          > > > 2. As we know client_acknowledge happens at the session level:
          > > > Acknowledging a consumed message automatically acknowledges the
          > > > receipt of all messages that have been consumed by its session. For
          > > > example, if a message consumer consumes ten messages and then
          > > > acknowledges the fifth message delivered, all ten messages are
          > > > acknowledged.
          > > > -- this is the problem -- we want to acknowledge each msg
          > > > individually so that only the processed msg is acknowledged although
          > > > there are x number of msg being retrieved. By doing that we won't lost
          > > > any msg in case the JMS client crashes.
          > > >
          > > > It is a challenge, isn't it? Might well not be one for you, if you
          > > > know the trick. If you do, could you share with us? Thanks a lot.
          > > >
          > > > Mike