Page History

...

You can then monitor ActiveMQ using the Web Console by pointing your browser at http://localhost:8161/admin/ and then topics page

Single point of failure

The setting above is sufficient in a staging environment but is a single point of failure in a production environment. So we need to create a cluster of ActiveMQ brokers. Since they should not consume much resources (only 256MB of memory at max and not much CPU cycles), we can put each instance on the same machines than the OFBiz instances.

There is a simple way to load balance ActiveMQ queues in an ActiveMQ cluster. But, as explained above, tough we use async services for clearing distributed caches, it does not make sense for us to use queues since we need to broadcast messages. There is also the so called virtual destinations solution but it's a bit complicated and it seems still uses a queue underneath. After some resarches, I have finally decided to go with the the Failover Transport solution.

It's fairly simple to set through JNDI. For this we only need to replace in jndi.properties files

java.naming.provider.url=tcp://172.18.7.4:61616

by

java.naming.provider.url=failover:(tcp://172.18.7.4:61616,tcp://172.18.7.5:61616)?randomize=false&backup=true&trackMessages=true

See Transport Options for details on the 2 last parameters. There is a also a link at bottom of this page if ever you need to escalate more smoothly dynamic setting of failover. But it would need more work in OFBiz...

Some possible pitfalls

This section can be bypassed but may help
I first installed ActiveMQ 5.5.0 on my developement machine on XP. When I ran OFBiz I got this non blocking error

...

I firts wondered if this was due to ActiveMQ itself or something else in OFBiz which was interacting with activemq JAR. I then thought that, to work with ActiveMQ, it needed a special setting and following the advice I (hastily) installed the last SLF4J version (slf4j-simple-1.6.1.jar) in the framework/base/lib OFBiz directory. I then got a message "Multiple bindings were found on the class path". But as all was working correctly I thought it was only a warning about using a slf4j version in ActiveMQ and another in OFBiz. Later when I began to run the Distributed Cache Clearing Mechanism on the cluster I crossed some issues and began to wonder what was wrong. It took me a moment to realize ''<<SLF4J will default to a no-operation (NOP) logger implementation>>'' sent me the wrong way. Actually I did not need to add any slf4j JAR, pfew...

Single point of failure

The setting above is sufficient in a staging environment but is a single point of failure in a production environment. So we need to create a cluster of ActiveMQ brokers. Since they should not consume much resources (only 256MB of memory at max and not much CPU cycles), we can put each instance on the same machines than the OFBiz instances.

There is a simple way to load balance ActiveMQ queues in an ActiveMQ cluster. But, as explained above, tough we use async services for clearing distributed caches, it does not make sense for us to use queues since we need to broadcast messages. There is also the so called virtual destinations solution but it's a bit complicated and it seems still uses a queue underneath. After some resarches, I have finally decided to go with the the Failover Transport solution.

It's fairly simple to set through JNDI. For this we only need to replace in jndi.properties files

java.naming.provider.url=tcp://172.18.7.4:61616

by

java.naming.provider.url=failover:(tcp://172.18.7.4:61616,tcp://172.18.7.5:61616)?randomize=false&backup=true&trackMessages=true

See Transport Options for details on the 2 last parameters. There is a also a link at bottom of this page if ever you need to escalate more smoothly dynamic setting of failover. But it would need more work in OFBiz...