Can you elaborate on what functionality was identified as missing? We're
always looking to improve things so if there's a legitimate need/gap it's
worth exploring.
Justin
On Mon, Oct 23, 2017 at 1:00 PM, pypen wrote:
> We actually use more than 2 nodes, but still an even amount.
> About the p
We actually use more than 2 nodes, but still an even amount.
About the prime-time ready: A consultant told me that some functionality was
missing.
Maybe I will look into Artemis.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
> I DON'T want persistent messaging via KhahaDB (or jdbc). I don't want to
introduce a database, a NAS or shared folders (I'm on windows).
You could move to Artemis and use the network replication functionality
which doesn't use a database, NAS, etc. The only concern here is with
split brain whic
:)
You are right. And you are wrong.
I DON'T want persistent messaging via KhahaDB (or jdbc). I don't want to
introduce a database, a NAS or shared folders (I'm on windows).
I DO want in memory behavior similar to it, where two brokers share their
messages (in memory) so that if both brokers die, m
ActiveMQ 5.x allows messages to be delivered to local consumers over remote
ones via the decreaseNetworkConsumerPriority property as described at
http://activemq.apache.org/networks-of-brokers.html. JMSXGroupID will not
achieve this goal for the reasons you described.
Also, I dispute your claim th
I don't think of Artemis as "not really prime-time ready yet." The Artemis
code-base was based on the HornetQ message broker which has served
commercially as the JMS implementation in Red Hat's JBoss Enterprise
Application Platform (EAP) 6.x since 2012. Artemis itself has served in
the same capac
Thanks guys.
I am a little hesitant since I heard that artemis is not really prime-time
ready yet.
But I might give it a shot.
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Persistent messages in artemis are pretty fast. You should consider
persistent.
The fact you need them reliable means you need them durable.
On Fri, Oct 13, 2017 at 3:32 PM pypen wrote:
> Thank you both for your answers.
> Yes, Justin, that's what I meant (non-persistent messaging).
>
> I guess
> Is it for example possible to force messages to be always sent to a local
consumer, if one exists, otherwise to a remote consumer (if one exists and
no local consumer is running)? And if the local consumer starts again to
send all messages to the local consumer?
I'm not familiar with the intrica
Thank you both for your answers.
Yes, Justin, that's what I meant (non-persistent messaging).
I guess, I will have to look into different solutions.
Is it for example possible to force messages to be always sent to a local
consumer, if one exists, otherwise to a remote consumer (if one exists and
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:
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
> 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 wrote:
> Hi,
> I am trying to solve a problem and I am wondering if Virtual Topics provide
> a solution for the pr
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 consum
14 matches
Mail list logo
