Can a Storm topology read from RabbitMQ queue at runtime? The topology is submitted in a cluster using StormSubmitter class.
Yes, it can. You can pretty much do anything. If you are asking whether is a pre-made spout for RabbitMQ, I don't know an established one but there are a few according to google.
Related
I'm investigating the usage of some message broker that does not depend on any external services. I hit upon ActiveMQ which was using replicated LevelDB and that apparently required ZooKeeper services. With ActiveMQ now switching to KahaDB, is zookeeper still required for using ActiveMQ ?
Any recommendations on what the best message broker would be, my deployment does not deal with high scale pub-sub. I'm looking for something very lightweight that can support reliable message delivery, persistent messages and HA.
I found the answer to my own question
http://activemq.apache.org/kahadb-master-slave.html
yes, even KahaDB requires zookeeper at the moment
ActiveMQ does not require ZooKeeper to run, the default store KahaDB does not have a replication feature such as that in LevelDB and so does not need any ZooKeeper instances.
For HA you might want to look into ActiveMQ Artemis which offers solutions beyond what exists in ActiveMQ proper.
I have a project where we are using Rabbit MQ has message broker, I have below concern, please help on the same.
If Rabbit MQ goes down, how we can retrieve the queued message.is there any configuration in rabbit MQ?
Can we implement same in java thread and collection combination, that can be used as alternative to rabbit MQ? if yes help with an example.
'You should listen to ShutdownListenercallback on both Connection and Channelclasses'. By this way, you know if the queue is down. After that, you need to re-transmit your queued messages. This is what official documentations says. https://www.rabbitmq.com/reliability.html
Of course you can implement your own library, but you have to think if this would be better for you. I suggest you not to do that. RabbitMQ is a well-known open source library that many people use and trust for years. I think there is no side-effect using that in any project.
Deploy RabbitMQ on Kubernetes with stateful sets. This will replicate state in multiple instances. One of them will be primary. Failover will be handled by Kubernetes.
See https://kublr.com/blog/reliable-fault-tolerant-messaging-rabbitmq-kublr/
Is not Apache Kafka another implementation of JMS?
I am using JMS+AMQ in my application, and migrating to Apache Kafka. Do I have to change all JMS codes?
No, Kafka is different from JMS systems such as ActiveMQ.
see ActiveMQ vs Apollo vs Kafka
Kafka has less features than ActiveMQ, as the stress has been put on performances. So before migrating, check that the features you use in AMQ are in Kafka.
However, there is an open suggestion for a bridge between JMS and Kafka, to allow exactly what you need. Maybe the provided links can help you
https://issues.apache.org/jira/browse/KAFKA-1995
Actually, the two are not the same. And with a little more time seeing the two co-exist - and listening to problems and happy points from those deploying each in the field - there is a little more to say about each one.
Firstly, JMS supports both point-to-point messaging (where messages are sent to single consumers; the consumers themselves maintain their message queues) and the publish-and-subscribe (pub/sub) model (where messages are written to a single topic, and consumers, independently, decide which messages to consume).
In a point-to-point messaging architecture, message producers and consumers know each other, where as in a pub/sub model they do not. Apache Kafka focuses on a pub/sub model, maintaining a separate log/topic from which consumers read from offsets. Kafka is also built for the cloud, with high-throughput a core consideration.
Many in our community and at meetups throw their hands up in frustration at MOMs (message-oriented middlewares) like JMS and switch to Kafka, for, what boils down to one reason: scalability. They argue that Kafka is better suited for scale than other MOMs because Kafka maintains a partitioned topic log. In so doing, Kafka can split up message flow to groups of consumers by partition and batch transmit the messages.
This concept also allows Kafka to have more granular control over ACLs (access control) to Kafka Consumers, although there are some issues there, which Apache Pulsar is addressing.
Finally, on Kafka, since the client/consumer decides which messages to consume (by offset in the topic), this removes some of the producer-side complexity of routing rules built into MOMs like JMS.
There's more differences than that, but this is a distillation of some of the ones that keep coming up! Hope this helps.
No, Kafka uses its own non-standard protocol and clients.
However, there's a 3rd-party JMS Client for Kafka from Confluent.
NServiceBus Distributor/Worker pattern makes perfect sense for MSMQ due to the hard requirement of local input queues.
But this is not the case with RabbitMQ, I am trying to understand how and when the NServiceBus distributor is relevant with RabbitMQ. With RabbitMQ multiple workers can read from the same remote queue.
The actual scenario is similar to using an AWS auto-scaling group to scale out workers pointing to a high available RabbitMQ cluster. Now avoiding distributor altogether makes the setup much simpler to build, test and provision.
Thoughts?
As RabbitMQ transport falls into the broker style bus, so, in your use case, it would make more sense not to use the distributor.
The same goes for all broker-style transports, where you can use a competing consumer pattern to scale out.
NServiceBus is an excellent system and does wonders in most message queuing system where you don't have an integrated distributor (which you do with exchanges in RabbitMQ). We use NServiceBus here at our company.
Azure Queues and MSMQ are perfect examples of such queuing technologies.
NServiceBus handles the distribution internally and therefore reproduces this capability for you.
However... If you are blessed with the possibility of imposing what queuing technology you can use, then I would highly encourage you to look into RabbitMQ and a product (Open Source) called MassTransit
http://masstransit-project.com/
MassTransit can in turn function in the two modes and will either delegate or simulate the distribution for you - however I nonetheless have a soft spot for NServiceBus as do our senior devs here.
Per this page...
http://docs.particular.net/nservicebus/load-balancing-with-the-distributor
Using the distributor is only useful when using MSMQ - if you aren't using MSMQ then there is no point. RabbitMQ and other transport will allow access to the same queue from multiple consumers, while MSMQ will not. The distributor in a nutshell will take messages from the main queue and distribute them across multiple worker queues as they report that they are done with whatever they are working on.
I'm experiencing an issue with ActiveMQ and would like to trace/view all ActiveMQ activity. The only log file I can find is one associated with persistent data (if this is turned on). Are there any other log files I view or generate to tell me what's happening under the hood of ActiveMQ and why my consumers aren't consuming messages? Any other suggestions?
Thanks in advance!
activemq has a jmx interface that you can connect to.
this gives us access to consumer counts messages queued dequeue and all sorts of data on memory usage etc.
http://activemq.apache.org/jmx.html
Has all the details to get you started.
I find it excellent in finding out whats going on with activemq.
A quick firing up of jconsole and you will be well on your way to finding out what is going on.
Paul
Agreed. Also you can add the logging interceptor which helps.
Finally for browsing messages, moving them, creating/deleting queues and sending message I highly recommend the new web console for ActiveMQ, Camel and many other plugins: hawtio
Try HawtIO. Assuming you are not using Active MQ 5.9 you can add this feature to your broker. It is a much better web console and a good JMX monitoring utility as well.
http://www.christianposta.com/blog/?p=315