I am using replicated levelDB in ActiveMQv5.11.1. I have a use case of delayed message handling. I have gone through the documentation and it looks like I can't use it with leveldb (Only kahadb supports scheduler)
I have also seen couple of posts about In-memory scheduler (https://dzone.com/articles/coming-activemq-v511-memory) but I think I need to run the broker with persistent=false.
Is there a way I can use In memory scheduler with replicated levelDB ?
Thanks,
Anuj
When using LeveDB if you've enabled scheduler support and you have the activemq-kahadb-store jar on the classpath the broker will still create a Job Scheduler store as the default store is based on KahaDB but is not intrinsically tied to it so it can be created standalone.
There are also some setters in the broker service where you can set the scheduler store you want to use as well.
Related
I have an instance of ActiveMQ 5.16.4 running that is using MySQL as a persistent data storage. Recently the MySQL server had some issues, and ActiveMQ lost its connection to MySQL. That caused multiple Spring microservices to throw errors because ActiveMQ wasn't working.
Is it possible to have master/slave ActiveMQ running where master and slave uses separate persistence storage?
I have done some research and found "pure master slave", but it says that it is deprecated and not recommend to use and will be removed in 5.8. It says to use shared storage which I am trying to avoid (cause my problem is what if storage itself is down).
What are my options to keep running ActiveMQ if it loses connection to database?
If you're using ActiveMQ "Classic" (i.e. 5.x) then your only option is to use shared storage between the master and the slave. This could be a shared file system or a relational database. This, of course, is a single point of failure.
However, there are both file system and database technologies that can mitigate this risk. For example you could use a replicated file system (e.g. Ceph or GlusterFS) or a replicated database (e.g. MySQL).
You might also consider using ActiveMQ Artemis (i.e. the next-generation broker from ActiveMQ) which supports replication natively.
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'd like to take a RequestDTO that has been POST'd to a ServiceStack service and push that to Redis with the built in messaging capabilities provided by ServiceStack.Server RedisMqServer. This message should be durable (if it was successfully pushed) in the sense that it should survive reboots of the Redis server (if that were to happen) and other unfortunate events. It should persist until it has been read/processed by another yet to be determined service.
Is this Pub/Sub, Request/Response, or just Request/no Response?
Thank you, Stephen
You need to ensure your Redis Server is configured to persist to disk, the docs on redis persistence describe how to configure Redis RDB Snapshots and support for Append Only File.
Important note about Append Only File in Redis:
The suggested (and default) policy is to fsync every second. It is both very fast and pretty safe. The always policy is very slow in practice (although it was improved in Redis 2.0) – there is no way to make fsync faster than it is.
In practice means there is a chance to lose data if redis-server process terminated unexpectedly.
ServiceStack's Rabbit MQ Server provides a more durable option for MQ Services which has true ACK support so a message is only removed from the MQ Broker when the client explicitly acknowledges to do so.
My group is looking to distribute our ActiveMQ queues across multiple brokers to achieve high availability. Of the three supported master-slave setups (pure, shared filesystem, JDBC) we are considering shared file system and JDBC.
I am seeing conflicting statements within the ActiveMQ documentation. Can, or can not, JDBC master-slave setup use ActiveMQ's high-performance journal?
On this page, ActiveMQ claims that
it cannot use the high performance journal.
On this page, ActiveMQ suggests that the two can, in fact, be used together:
For long term persistence we recommend using JDBC coupled with our high performance journal.
Can anyone shed light on this apparent conflict?
you should not use journaling with JDBC master/slave because the journal is not replicated. Any messages in the journal of the master that have not yet been batch submitted to the jdbc store will be isolated till restart. ie: the journal is not visible to the slave.
I have tried and tested the JMX API and it is pretty simple to use and provides a vast number of statistics required for monitoring ActiveMQ.
But the problem is, i dont want to monitor my ActiveMQ remotely and also i dont want to use another API.To be more precise, i want to use the JMS API itself to get statistics related to various destinations and the broker itself.
Advisory messages seem to be an alternative but they provide limited Amount of Administrative Messages to monitor.
Any input is highly appreciated...
There is no built-in support for this. But you can implement a JMS topic which publishes the monitoring data every few seconds. Make the connection non-persistent so that it doesn't pile up when there are no listeners or when they loose connection.
Now you can write a client that connects to this topic and it will receive updates.
AMQ-2379 resulted in a broker plugin for grabbing statistics from destinations by sending a simple JMS message. Check out the docs that show how to use it here:
http://activemq.apache.org/statisticsplugin.html
The statistics plugin is available in the 5.3 release.
You can checkout this http://issues.apache.org/activemq/browse/AMQ-2379, it will be avaiable in upcoming 5.3.0 release
There's a blog post queued up to go on http://issues.apache.org/activemq/browse/AMQ-2379 - will post it in a couple of days or so