I have 3 applications running on my server. They communicate via JMS. Works like a champ! (or is it charm?)
I am currently able to run 2 of the applications in a single JVM (we’ll call them Application A & B)
But now when these guys communicate, they have to go out of process to talk to a JMS broker which sends the message right back. Dumb. Fortunately, ActiveMQ lets you embed a broker, which makes JMS “as efficient as pure RMI, but with all the usual JMS features of location independence, reliability, load balancing etc.” Cool! So far so good.
So I run a single embedded broker in JVM 1 that A&B talk to. But C (in JVM2) can’t talk to that guy. So I give the embedded one an external facing TCP connector. Now C can talk to A/B with a single network (process) hop (previously it was 2). Not as good as RMI, but better than before. Still good!
But here’s my dilemma: I want to bounce JVM1. If I take it down, my broker goes down too. So process C (JVM2) loses the connection, can’t queue messages anymore, and has to be taken down too. Problem.
Anyone have any suggestions for this situation? Here are my thoughts:
a) I could run an embedded JVM for A&B and a standalone one for C. That would solve the broker-going-down problem, but means 2 hops for C to get to A/B.
b) I could run an embedded broker with both in-memory and TCP connections AND a standalone broker. Then I would configure process A to use embedded TCP by default and failover to standalone running on a separate port. This seems to be the best of all worlds, except kind of strange to run so many brokers on a single box. Definitely adds another element of complexity and costs more cycles…
This may never actually be a problem for me in production (on the current setup) b/c I’ll be running a cluster, so when I bring down JVM1, the other guy will just route to other brokers in the cluster. That’s fortuitous, but also seems like an expensive and complicated solution.