You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by artnaseef <ar...@artnaseef.com> on 2015/12/01 01:04:37 UTC
Re: JDBC 300K messages stuck in queue, consumers receives messages
when manually browsed the queue
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.
Re: JDBC 300K messages stuck in queue, consumers receives messages
when manually browsed the queue
Posted by "Takawale, Pankaj" <pa...@dowjones.com>.
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" <pa...@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 <ar...@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.
> > >
> >
>
Re: JDBC 300K messages stuck in queue, consumers receives messages
when manually browsed the queue
Posted by Tim Bain <tb...@alumni.duke.edu>.
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" <pa...@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 <ar...@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.
> >
>
Re: JDBC 300K messages stuck in queue, consumers receives messages
when manually browsed the queue
Posted by "Takawale, Pankaj" <pa...@dowjones.com>.
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 <ar...@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.
>