I've started consumer with no selector on it. It started receiving all the messages, and I'm filtering out the unwanted in application.
Thank you, Pankaj On Tue, Dec 1, 2015 at 4:39 PM, Tim Bain <tb...@alumni.duke.edu> wrote: > If you control the producers and are willing to lose the unconsumed > messages, you can have the producers set the JMSExpiration header so that > messages expire if they're not consumed after a certain amount of time. > > But that won't help you get out of the current problem. For right now, if > you can figure out a selector that will match only the problem messages, > you could write a consumer that uses that selector and simply acks the > message (discarding it) to clear things up. > > Tim > On Dec 1, 2015 12:43 PM, "Takawale, Pankaj" <pankaj.takaw...@dowjones.com> > wrote: > > > Yes, there are messages in the queue that do not match any of the > consumer > > selectors. I wonder why they landed up in the queue. > > I've also noticed the high CPU usage that you mentioned. > > > > I've one VirtualTopic, and around 50 selector-aware queues on it. System > > processes around 40K different JMSXGroupIDs. So each selector-aware queue > > only receives the subset of full fire-hose based on the consumers' > > selectors subscription. We use JMSXGroupID for the filtering, as the same > > attribute would be used for the load-balancing purpose across multiple > > queue consumers. So there are multiple consumers subscribed with the same > > selector expression. > > > > I've tried to upgrade activemq to v5.12.2, and nightly 5.13 snapshot > > v5.13-20151130.033036-75. It showed the same symptoms. > > > > Is there any way to get out of this situation? Any way to purge the > > unmatched messages from the queue? If there is no any existing way, could > > you please point me to the code sample for unmarshaling the message from > > activemq_msgs table, so that I could write cleanup job? > > > > Thanks > > Pankaj > > > > > > > > > > > > On Mon, Nov 30, 2015 at 7:04 PM, artnaseef <a...@artnaseef.com> wrote: > > > > > Are there messages in the queue that do not match any of the consumer > > > selectors? If so, only "MaxPageSize" messages (300 by default) can > reach > > > the head of the queue before dispatching stops. I believe that number > > > increases while browsing, hence the reason browsing temporarily > aleviates > > > the problem. > > > > > > Note that I'm curious why the use of selectors on JMSXGroupID since the > > > entire purpose of JMSXGroupID is to select an exclusive consumer for a > > > subset of the queue's messages (the subset that shares the same group > > ID). > > > > > > Also note that JMSXGroup's share a similiar issue related to > MaxPageSize, > > > if > > > any one of the consumers is slow. > > > > > > Finally, note that the backlog of messages with selectors and > JMSXGroups, > > > when messages cannot be dispatched (due to no available, matching > > > consumer), > > > leads to a significant increase in CPU usage. > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://activemq.2283324.n4.nabble.com/JDBC-300K-messages-stuck-in-queue-consumers-receives-messages-when-manually-browsed-the-queue-tp4704330p4704436.html > > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > > >
