Replicate Activemq Message to once server to another server activemq - activemq

Q: we want publish same message in different Activemq servers. can we have any approach. like we will publish once and activemq changes will give a forward that message to another instance.
or is there any way we can do it by the activemq config changes?

There is not much context in the question but a simple Topic together with Network of brokers should do that.
The idea is that you connect multiple brokers using "network of brokers", then messages sent to a topic will be available to all clients on all brokers throughout the network.
There are a lot of corner cases when it comes to network of brokers and topics, but it should do the work.

Related

ActiveMQ topics vs RabbitMQ Direct exchanges

We are currently looking at ActiveMQ.
Previously we've used RabbitMQ and in particular Direct exchanges whereby a producer can send a single message to a broker which then fans this out onto 1:N other queues.
We would like a similar setup in ActiveMQ where the broker holds the configuration for which messages go where, rather than the services sending messages directly to specific queues or consumers needing to subscribe to specific topics.
I've dug into the documentation and found Virtual Topic Composite Destinations which looks to provide this functionality.
What I am trying to understand now is if this is the ActiveMQ recommended approach and if there are any pitfalls I should be wary of?
Any ActiveMQ war stories much appreciated!

find where activemq is running

I am starting to study ActiveMQ, and there is one question that I must have the answer as soon as possible: is it possible for a, say, console program, to know the IP of the machine where ActiveMQ is running without any previous information, like configuration file, or a parameter passed to the program? I wonder if ActiveMQ answers to some type of broadcast network message, reporting the IP of the computer it is running.
Thanks!
While your question is a bit vague on actual requirements and network capabilities etc, the most reasonable answer to this is to use discovery via multicast to locate a broker to connect to. There is documentation for this here, here, here and some here and more if you bother to search Google.
When you enable discovery on the broker's transport connector it will broadcast via multicast the IP address and port where a client can connect. You should do some research and even browse the ActiveMQ code to see how this works.
No, that's not possible. If all of the world's ActiveMQ servers were broadcasting their connection info to every producer or consumer in the world, that would be a ton of traffic. And if they were, how's a producer of consumer supposed to know which one to connect to, without being told? You have to tell the client how to reach the broker, and it's not a big deal to do.

MassTransmit - Distributed Messaging Model - Reliable/Durable - NServiceBus too expensive

I would like to use MassTransmit similar to NServiceBus, every publisher and subscriber has a local queue. However I want to use RabbitMQ.
So do all my desktop clients have to have RabbitMQ installed, I think so, then should I just connect the 50 desktop clients and 2 servers into a cluster?
I know the two servers must be in the same cluster. However 50 client nodes, seems a bi tmuch to put in one cluster.....Or should I shovel them or Federate them to the server cluster exchange?
The desktop machine send messages like: LockOrder, UnLock Order.
The Servers are dealing with backend hl7 messages.
Any help and advice here is much appreciated, this is all on windows machines.
Basically I am leaving NServiceBus behind, as it is now too expensive, they aiming it at large corporations with big budgets, hence Masstransmit.
However I want reliable/durable messaging, hence local queues on ALL publishers and ALL subscribers.
The desktops also use CQS to update their views.
should I just connect the 50 desktop clients and 2 servers into a cluster?
Yes, you have to connected your clients to the cluster.
However 50 client nodes, seems a bi tmuch to put in one cluster.
No, (or it depends how big are your servers) 50 clients is a small number
Or should I shovel them or Federate them to the server cluster exchange?
The desktop machine send messages like: LockOrder, UnLock Order.
I think it's better the cluster, because federation and shovel are asynchronous, it means that your LockOrder could be not replicated in time.
However I want reliable/durable messaging, hence local queues on ALL publishers and ALL subscribers
Withe RMQ you can create a persistent queue and messages, and it is not necessary if the client(s) is connected. It will get the messages when it will connect to the broker.
I hope it helps.
I have a FOSS ESB rpoject called Shuttle, if you would like to give it a spin: https://github.com/Shuttle/shuttle-esb
I haven't used NServiceBus for a while and actually started Shuttle when it went commercial. The implementation is somewhat different from NServiceBus. I don't know MassTransit at all, though. Currently process managers (sagas) have to be hand-rolled in Shuttle whereas MassTransit and NServiceBus have this incorporated. If I do get around to adding sagas I'll be adding them as a Module that can be plugged into the receiving pipeline. This way one could have various implementations and choose the flavour you like :)
Back to your issue. Shuttle has the concept of an optional outbox for queuing technologies like RabbitMQ. Shuttle does have a RabbitMQ implementation. I believe the outbox works somewhat like 'shovel' does. So the outbox would be local and sending messages would first go to the outbox. It would periodically try to send messages on to the recipients and, after a configurable number of attempts, send the message to an error queue. It can then be returned to the outbox for further attempts, or even moved directly to the recipient queue once it is up.
Documentation here: http://shuttle.github.io/shuttle-esb/

why duplicate messages happen in multi brokers of activemq cluster?

There're 2 brokers which are configured as a cluster through network connector.
Allways, messages are sent by a producer to broker0, and consumed by a consumer of broker0. But we found that some duplicated messages are sent to broker1, even broker0 are working well.
That's say, this duplicated messages are contains in both broker0 and broker1. Could anyone tell me the reason ?
Thank you
Such kind of situation can occur, if you are trying to use two independent ActiveMQ instances in a cluster and client has been given access to both broker URLs.
The solution is to use the master-slave feature that is designed to provide high availability.

Is it possible to configure multiple queues to one shovel?

I've got a webservice that accepts messages that can be sent to a RabbitMQ cluster using whatever queue they define. This is so front-end devs can send messages via javascript.
I want to make the webservice more robust so that when we have network trouble, the webservice can still accept messages and then handle them when the network is back up. After some initial reading, it seems that the Shovel plugin should handle this nicely.
What I was thinking was to install a local instance of RabbitMQ on the webservice box with shovel turned on. I can then send all messages through the local RabbitMQ instance and have it push all messages to the cluster and deal with the network problems.
My problem is after looking at the documentation it seems that I have to configure every queue I want to forward to in the shovel config file. If that's the case I'm not sure this will work since we allow clients to define a queue through the webservice on the fly.
I would like to have the webservice take the messages, hand them off to the local rmq instance and have it pass the messages off to the cluster using the same queues/exachanges/etc.
Has anyone tried this or can explain how the shovel plugin works?
Have you considered sending messages to an exchange instead of a queue. Send all messages to one exchange possibly a topic exchange if you need that kind of flexibility. Then have the consumer handle the different messages or different queues from the exchange. Sending to one exchange would make configuring the shovel considerably easier.