I see that Tim closed your JIRA as Not A Problem, but didn't explain why. In case you weren't sure why this is expected behavior, here's an explanation:
Messages get read from the broker's persistent store via a cursor (see http://activemq.apache.org/message-cursors.html), which is assumed to always have the next message any consumer might want. (This is sometimes a bad assumption, but it's the design.) A cursor has a fixed size; once it's full, a new message cannot be read into the cursor (and therefore delivered to a consumer) until enough messages are read from the cursor to free up space for the new message. If none of the existing messages in the cursor are read, nothing happens. In your case, you're intentionally creating messages that won't be consumed. These messages build up in the cursor, and once it's full, none of the new messages can get into the cursor so none of them can get dispatched so none of them get consumed. And for that reason all messages stop flowing. Tim's suggestion to tweak the cursor size wouldn't solve this problem, it would just delay the onset, in the same way that increasing your JVM heap size when you have a memory leak only delays the problem rather than solving it. The underlying issue is that you're doing something wrong: you're publishing messages to a queue without ensuing that all of them will be processed (consumed or discarded) in a timely manner. So either make sure your consumers have selectors that match all messages or configure something to discard messages if they aren't consumed in a timely manner (JMSExpiration plus the DiscardingDLQPlugin is what we use). Tim On Feb 11, 2015 10:22 PM, "krishy" <calvinkri...@gmail.com> wrote: > I went ahead and created a ticket as well: > > https://issues.apache.org/jira/browse/AMQ-5582 > > > > -- > View this message in context: > http://activemq.2283324.n4.nabble.com/Consumer-queues-of-virtual-topic-and-the-web-console-tp4689995p4691427.html > Sent from the ActiveMQ - User mailing list archive at Nabble.com. >
