Hi Paul- During a failover, the ActiveMQ client library must recreate the connection, session, producer and/or consumer context. A random ‘ack’ coming back to a broker that did not dispatch the message would be ignored.
Keep in mind that during any sort of failover or HA scenario with any type of computer system (database, message queue, etc) you must balance performance with exact delivery. If you must have exact message delivery (ie, no ability to handle the risk of duplication) then your best option is to use XA transactions which provide the best reliability. However, XA transactions incur a performance trade-off due to higher latency. If your consumer app can handle the risk of duplication during a failover, then SESSION_TRANSACTED (non-XA), INDIVIDUAL_ACK and CLIENT_ACK can be used. -Matt Pavlovich > On Mar 11, 2023, at 7:05 AM, Paul McCulloch <paul.mccull...@ifs.com.INVALID> > wrote: > > Thanks for the reply Matt. > > I couldn't find anything in the documentation that indicated that failover:() > to a single load balanced URL was supported. > > This made me somewhat nervous about hiding the fact that different brokers > might handle different requests from the client. I imagined a situation where > a client dequeued a message from broker 1 and then acknowledged that message > to broker 2 - and considered that perhaps the client needs to know that > different brokers are involved. > > If there was some indication, in documentation or code, that this was a > legitimate way to work then I, and my networking team, would be delighted! > > Paul > > ________________________________ > From: Matt Pavlovich <mattr...@gmail.com> > Sent: Friday, March 10, 2023 7:28 PM > To: users@activemq.apache.org <users@activemq.apache.org> > Subject: Re: ActiveMQ failover transport considers http URIs that share the > same hostname/IP & port as duplicates - the path is ignored > > Hello Paul- > > Yes, please file a JIRA. However, if you are a behind a load balancer, it is > valid to host a single hostname in the URI > failover:(https://company.com/broker) and have the load balancer abstract the > number of brokers. > > In your setup, is there a reason to require the need the path to change for > the different brokers behind a load balancer? > > Thanks, > Matt Pavlovich > >> On Mar 10, 2023, at 6:28 AM, Paul McCulloch <paul.mccull...@ifs.com.INVALID> >> wrote: >> >> Hi, >> >> I've found what I think is a bug in the failover transport in 5.x. If I use >> two https URLs that share a hostname & Port (https://company,com/broker/1 & >> [https://company,com/broker/2)]https://company,com/broker/2) then the second >> doesn't get added to the failover transport's internal list of URIs to try. >> >> This is due to >> org.apache.activemq.transport.failover.FailoverTransport.compareURIs(URI, >> URI) only considering IP & Port to determine if two URI's are distinct. Path >> should be considered by (at least) http(s) IMHO. >> >> The use case for this is an active/passive cluster behind a load balancer >> exposed with a single IP. I can work round by using an explicit port on my >> second broker - but that's fragile. >> >> Is this a bug? If so, how do I resolve this? Is creating a bug on >> https://issues.apache.org/jira/projects/AMQ/ and submitting a PR my best bet? >> >> Thanks, >> >> Paul >> ________________________________ >> Confidentiality notice and disclaimer >> This e-mail is private and may contain confidential information. You must >> not use, disclose, or retain any of its content if you have received it in >> error: please notify its sender and then delete it. Any views or opinions >> expressed in this e-mail are strictly those of its author. We do not accept >> liability for the consequences of any data corruption, interception, >> tampering, or virus. > > ________________________________ > Confidentiality notice and disclaimer > This e-mail is private and may contain confidential information. You must not > use, disclose, or retain any of its content if you have received it in error: > please notify its sender and then delete it. Any views or opinions expressed > in this e-mail are strictly those of its author. We do not accept liability > for the consequences of any data corruption, interception, tampering, or > virus.
