activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Lindwall (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Deleted] (AMQ-5897) Slave fails to deliver messages
Date Mon, 27 Jul 2015 18:49:05 GMT

     [ https://issues.apache.org/jira/browse/AMQ-5897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

John Lindwall updated AMQ-5897:
-------------------------------
    Comment: was deleted

(was: The problem I encountered sounds exactly like the issue you described in your blog post
("virtual topics to the rescue").  Not so much like the AMQ-4000 issue though.

The Virtual Topic solution sounds neat, however I am not interested in going off the JMS reservation
and writing custom code to solve this problem.  If I understand correctly, to use Virtual
Topics I need to rewrite my consumers to connect to a specially named queue instead of a topic.
 This approach will not be portable if we plug-in a different JMS broker.

We're now looking into using (yep!) ActiveMQ's JDBC Persistence to satisfy our requirements;
our performance needs are not tremendous so I am hopeful it will suffice.  It performs as
expected for fail-over scenarios, so that is good.

I appreciate your response on this issue!  Thanks. 

Is the jira protocol for me to now change the status of this issue to something like "As Designed"
or somesuch?
)

> Slave fails to deliver messages
> -------------------------------
>
>                 Key: AMQ-5897
>                 URL: https://issues.apache.org/jira/browse/AMQ-5897
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.10.0, 5.11.1
>         Environment: Solaris 5.11
>            Reporter: John Lindwall
>         Attachments: ActiveMQFailOverDurableMessageListener.java, ActiveMQFailOverMessageSender.java,
master1-activemq.xml, master2-activemq.xml, slave1-activemq.xml, slave2-activemq.xml
>
>
> When a slave takes over for a failed master, pending messages are not delivered.
> I have a 5.11 cluster consisting of 2 pairs of master/slaves: m1/s1 and m2/s2.  They
use multicast://default for their networkConnectors.  1 subscriber, 1 publisher, also both
using multicast urls. My subscriber is a durable subscriber. Msgs are persistent. 
> I am testing system robustness in the face of a master failure.  I have 3 test cases,
of which 2 behave as expected and 1 is problematic.  My publisher connects to a master, sends
a set of 10 persistent messages and exits.  The subscriber (durable) receives a message and
spends 1 sec simulating processing time, and waits for the next msg (auto-acknowledge). 
> For each test case I connect the subscriber, then publish the message set, then kill
a master after a few messages are received by the subscriber.  When the slave comes online
I expect the remaining msgs to be delivered. 
> 1. subscribe to m2, publish to m2, kill m2. Messages are all delivered 
> 2. subscribe to m1, publish to m2, kill m2. Messages are all delivered 
> 3. subscribe to m1, publish to m2, kill m1. Remaining msgs are NOT DELIVERED :( 
> In case #3, when m1 is killed I can see the subscriber reconnecting to m2.  The remaining
messages are not delivered at that time though.
> If I then connect the subscriber directly to s1 (using tcp:// url), the remaining msgs
are indeed delivered. I would have expected s1 to route the remaining msgs to m2 during the
test execution, but that did not happen. 
> When I "kill" the master I mean that I do "kill -9 XXXX".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message