How can you say that "acking happens as needed", when you're not acking the messages when you're done consuming them (which is when it's needed)? Clearly you're not acking as needed. Have all consumers ack messages when they're done consuming them, and tell us if you still think you have a problem. Better yet, switch to AUTO_ACK, unless you have a concrete reason (which you haven't yet given) why you need the control that comes with CLIENT_ACK.
Do you understand why setting a maxPageSize of 5000 solved your current problem? Also, I expect that with the setup you've described, 1/2 of the messages that get published to the queue will never run through your utility tool, a 1/4 will run through it once (as you intend), 1/8 will be passed through it twice (i.e. the original message will be consumed by the utility and republished, and then the republished message will be consumed again by the utility and re-republished), 1/16 will be passed through it three times, 1/32 will be passed through it four times, etc. Are you seeing that behavior? I also expect that if your MessageListener were offline, messages would pass through your utility again and again in an infinite loop, using huge amounts of CPU. Does that happen in that scenario? I think you've got a bad application design, which results in the two bad behaviors I described. Instead, you should have your message utility listen on the queue to which messages are originally published and then publish to a "processed" queue, on which your MessageListener would listen. This would ensure that every message passes once and only once through your utility. Alternatively, if your utility's business logic can be implemented in a Camel route that can be embedded in the broker, you can use that embedded route to modify the message before it gets enqueued, eliminating the need to have multiple queues (and eliminating a process that you have to monitor and maintain). But whether your business logic can be put into an embedded Camel route depends on what your business logic is and what resources it needs. Tim Tim On Tue, Dec 15, 2015 at 7:22 AM, dabayev <daba...@fortress.com> wrote: > Tim, > > I am currently playing in my dev environment. I have one consumer which is > event driven implementing MessageListener. This consumer is a client_ack > consumer and during my development I have not yet acked anything to not > remove the messages. My Listener does not at this point, just shows that it > received a message and does not remove it. > > My current queue size is about 900 messages for testing purposes. > > My utility tool does not implement MessageListener, it just creates a > connection and tries to consume a message based on JMS ID. It then will > copy > the message content to a new message and queue it. The old message is then > acked and removed from the queue. > > Between my message listener and my utility the queue size does not change. > I > did not have this problem when queue size I tested with was smaller. After > reading on this subject I set the <policyEntry queue=">" maxPageSize="5000" > maxBrowsePageSize="5000"/> and this helped with my message listener. > > I hope this describes my setup better. I have read everything about round > robin and tried different preFetch configs. Please let me know if I am not > clear on something. > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Issue-with-MessageConsumer-and-MessageSelector-tp4704870p4704979.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
