Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <CAPVVMa_Go8ffme6JSTO5rcm1qjUKx4=K=eY2btTfOdW_uyZ5JQ@mail.gmail.com>
References: <1507849707323-0.post@n4.nabble.com> <CAF+kE=TWD+A3t6KtEwL1oj7omkwBRrtWJN=ph7C9yPtxPoc6HA@mail.gmail.com>
 <CAPVVMa_Go8ffme6JSTO5rcm1qjUKx4=K=eY2btTfOdW_uyZ5JQ@mail.gmail.com>
From: Justin Bertram <jbertram@apache.org>
Date: Fri, 13 Oct 2017 08:20:51 -0500
Message-ID: <CAF+kE=SJD3XFzjoCrkqJ8zk78t9dtBsUh-A4CWf2niC7U0i=zg@mail.gmail.com>
Subject: Re: Message redelivery when producer broker killed (without persistence)
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary="94eb2c1104209aacdf055b6d86d7"
archived-at: Fri, 13 Oct 2017 13:20:55 -0000

--94eb2c1104209aacdf055b6d86d7
Content-Type: text/plain; charset="UTF-8"

Artemis does support this in a way via colocated lives and backups.
However, even then this is only valid for *persisted* messages.  The title
of the original email indicates this is needed for *non-persistent*
messages.  At least that's the way I understood it.


Justin

On Fri, Oct 13, 2017 at 7:44 AM, Tim Bain <tbain@alumni.duke.edu> wrote:

> I agree.
>
> The fundamental problem you're hitting is that in ActiveMQ 5.x, a message
> can exist in only one active broker, so networks of brokers move messages
> around via store-and-forward, as you described. For a message to be
> available to multiple brokers at the same time (such that it would still be
> available if a broker went down) you would need active-active clustering,
> which ActiveMQ 5.x doesn't support.
>
> However, ActiveMQ Artemis does support that feature, so you might want to
> consider switching to it to better support your use case.
>
> Tim
>
> On Oct 12, 2017 8:01 PM, "Justin Bertram" <jbertram@apache.org> wrote:
>
> > > So, am I just missing something or are virtual topics not a solution?
> >
> > I don't think virtual topics are a solution to your problem.
> >
> >
> > Justin
> >
> > On Thu, Oct 12, 2017 at 6:08 PM, pypen <pypen@gmx.net> wrote:
> >
> > > Hi,
> > > I am trying to solve a problem and I am wondering if Virtual Topics
> > provide
> > > a solution for the problem.
> > > I have 2 brokers in a network of brokers.
> > > Broker A has a producer to VirtualTopic.Test and a local consumer
> > > Consumer.A.VirtualTopic.Test (lets call it consumer A).
> > > Broker B has a local consumer Consumer.A.VirtualTopic.Test (lets call
> it
> > > consumer B).
> > > (All clients [producers and consumers] are connected to the local
> brokers
> > > only)
> > >
> > > Broker A and Broker B are both running, consumer A is running,
> consumer B
> > > is
> > > not running.
> > >
> > > I want to be able to kill consumer A and broker A entirely (pull the
> > plug),
> > > start consumer B and redeliver/process all messages that were not
> > > acknowledged by consumer A on consumer B.
> > >
> > > What I thought would happen (a very naive assumption) is that when a
> > > message
> > > is produced on the VirtualTopic.Test topic, both brokers will receive
> the
> > > message and when it is acknowledged by consumer A consumer B will not
> > > receive it (basically that the topics are treated as separate topics,
> but
> > > the queues as one). But the way it seems is that the message is handed
> > from
> > > broker A to consumer A, if consumer A does not acknowledge the message
> is
> > > handed back to the broker A, then handled over to broker B and then to
> > > consumer B. The problem is that when broker A is killed, that message
> is
> > > lost.
> > >
> > > I tried also to use a statically included destination
> > (VirtualTopic.Test),
> > > which seems to send copies of the messages to consumer A and consumer B
> > so
> > > that once consumer B starts, it will receive all messages (that did not
> > > expire), even the ones that were acknowledged already by consumer A.
> > (when
> > > both consumers are running all messages are delivered to both
> consumers)
> > >
> > > So, am I just missing something or are virtual topics not a solution?
> > >
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> > > f2341805.html
> > >
> >
>

--94eb2c1104209aacdf055b6d86d7--