activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Smith (JIRA)" <>
Subject [jira] Commented: (AMQ-674) Composite Destination persisted messages never get cleaned up, halt message producers
Date Tue, 04 Apr 2006 08:29:58 GMT
    [ ] 

Paul Smith commented on AMQ-674:

Just to be clear, so persistent Composite Destination support is basically useless in the
3.x series?

You see, the consumers are definitely keeping up with the producers, we definitely do not
have slow consumers here.  THere's no way that there is 32,000 unconsumed messages.  (In fact
the consumer nodes are sitting there doing nothing, not being delivered anything)

I don't mind upgrading to 4.x (they don't call me the upgrade-a-tron for nothing), just want
to clarify that there is no point pursuing a 3.2x fix?



> Composite Destination persisted messages never get cleaned up, halt message producers
> -------------------------------------------------------------------------------------
>          Key: AMQ-674
>          URL:
>      Project: ActiveMQ
>         Type: Bug

>   Components: Broker, Message Store
>     Versions: 3.2.1
>     Reporter: Paul Smith
>     Priority: Blocker
>      Fix For: 4.0 RC1

> 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:
For more information on JIRA, see:

View raw message