Hi Tim, My point is without failover (direct connection).
And yeah, agree about failover (failover deals with "network" outage, single broker included). Regards JB > Le 8 mai 2021 à 15:37, Tim Bain <tb...@alumni.duke.edu> a écrit : > > 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 <jpswe...@gmail.com> 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 <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 >>
