If clients use the failover transport ( https://activemq.apache.org/failover-transport-reference.html), reconnection is automatic when the broker becomes available once again. Failover isn't just for the case where you have multiple brokers, it also allows reconnection to a single broker, or to multiple brokers behind a single address (load balancer, DNS name, elastic/static IP, reverse proxy, whatever). I'd never consider running a long-lived consumer without it, and encourage you to consider it.
If your consumers use failover, then the only remaining question is how to restart the broker. You could do what you described, but 1) why wait for a cron, and 2) why check the database yourself if the broker will do it for you? I'd just use a wrapper script around the ActiveMQ broker process and just let it retry continuously until the connection succeeds. ActiveMQ has a wrapper script built in (https://activemq.apache.org/java-service-wrapper), so you shouldn't have to do anything custom here. JB's description of current behavior sounds different from what you describe seeing, so I'm not sure how to reconcile that apparent discrepancy. As for what the preferred behavior should be, I'll say that it's a lot easier to write the broker code correctly if you don't have to worry about how to cleanly exit an outage and resume normal operations, only how to detect the outage and exit, allowing all am-I-ready code to live on the initialization path. So I can see why remaining up and continuing to accept incoming messages would be beneficial in some situations, I think it would complicate the code and I'm not sure how much value it would actually provide. But if you feel strongly about it, submit an enhancement request in JIRA and see if you can make an argument for the value it would provide that convinces someone to work it. Tim On Sat, May 8, 2021, 4:22 AM J P <[email protected]> wrote: > Hi Tim. > > We are using the "Classic" ActiveMQ. > Would this behaviour be any different if switching to Artemis? > > In my view, the preferred behaviour if a client sends a msg to the queue > during DB-outage, the send request should "hang" or "block" until the DB > becomes available again (possibly throwing a "time-out error" after X > seconds, if still no DB-connection). > > The second choice would be that all send-operations immediately throws an > error back, until the DB becomes available again. > > Either of these behaviours seems far better than just promptly shutting > down the whole broker. > Esp. since getting all listeners to automatically reconnect after a broker > shutdown and restart is tricky and in practice rarely supported(?), I > think. > > So if the broker shuts down, then all listener-processes also need a > shutdown and restart, which would not be necessary if the broker stays up > during a temporary DB-outage. > > > would you be OK with having ActiveMQ restart repeatedly until the > > database is available again > > I have considered implementing this through a "crontab-script" or similar. > But the problem still is that all listeners also need to be restarted. > > So what the script would do then is, > when detecting that the broker has stopped, basically shutdown all > dependent processes, > then have the script loop and check for DB-availability, > when it comes back first restart the broker, then all the listeners. > This is outside the scope of ActiveMQ, though, since it requires monitor > and control over the whole environment. > > > ============================================ > > Tim Bain <[email protected]> > > Subject Re: ActiveMQ to auto-reconnect on jdbc db-failures? > > Date Fri, 07 May 2021 23:41:11 GMT > > If instead of staying up and attempting to reconnect to the database > (while > > still servicing requests without a database connection, whatever that > would > > mean), would you be OK with having ActiveMQ restart repeatedly until the > > database is available again? > > > > Also, is this 5.x or Artemis? > > > Tim >
