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 <tb...@alumni.duke.edu> > 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
