[
https://issues.apache.org/activemq/browse/AMQ-674?page=comments#action_35963 ]
Paul Smith commented on AMQ-674:
--------------------------------
hmm, it snipped my SQL
select container, count(*) from activemq_msgs group by container
Index2.EntityIncrementalIndexer
6
Index2.EntityIncrementalIndexer,Index1.EntityIncrementalIndexer
33228
activemq.log:
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN memory limit low - forced to remove expired messages:
PROCESSED_REQUESTS
14:45:03 WARN memory limit low - forced to remove expired messages:
INCOMING_REQUESTS
14:45:03 WARN memory limit low - forced to remove expired messages:
Index2.EntityFullIndexer
14:45:03 WARN memory limit low - forced to remove expired messages:
Index1.EntityFullIndexer
14:45:03 WARN memory limit low - forced to remove expired messages:
Index2.EntityIncrementalIndexer,Index1.EntityIncrementalIndexer
14:45:03 WARN memory limit low - forced to remove expired messages:
Index1.EntityIncrementalIndexer
14:45:03 WARN memory limit low - forced to remove expired messages:
Index2.EntityIncrementalIndexer
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
14:45:03 WARN Queue is full, waiting for it to be dequeued.
> Composite Destination persisted messages never get cleaned up, halt message
> producers
> -------------------------------------------------------------------------------------
>
> Key: AMQ-674
> URL: https://issues.apache.org/activemq/browse/AMQ-674
> Project: ActiveMQ
> Type: Bug
> Components: Broker, Message Store
> Versions: 3.2.1
> Reporter: Paul Smith
> Priority: Blocker
>
>
> well, we've just got bit by something huge.
> Previously we have been shipping messages from producer to consumer via a
> named Queue 'Index2.EntityIncrementalIndexer', where the machine index2 has a
> consumer called "EntityIncrementalIndexer" using persisted messages.
> The design used Composite destinations so that the destination could be:
> "Index1.EntityIncrementalIndexer,Index2.EntityIncrementalIndexer"
> and have the 2 hosts get sent the same message simply, and if one goes down,
> it'll catch up later. This gave us the ability to have a mirrored
> configuration, and go tertiary later if we want simply by adding a new name
> in the composite destation.
> With a single name, this works great, been working fine for months.
> Yesterday we activated the _true_ composite destination, and both machines
> started getting their messages fine.
> no problems so far, BUT, 12 hours later we have noticed that the broker has
> now stopped accepting messages, and a look at the activemq_msgs table shows
> 33228 messages
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
