Hi Alexandre, the gist link you provided is not accessible. Does your client logs any exceptions during the failover?
Regards, Domenico On Fri, 5 Sept 2025 at 09:34, <[email protected]> wrote: > Hello Justin, > Thanks for your answer. > > I confirm my cluster is formed properly (AFAIK) and the failover is > handled on the cluster side. > > I uploaded the following elements on this gist: > https://gist.github.com/alexandre-touret/3066f451161ce48243d24286 > > - Primary broker.xml configuration > - Replica broker.xml configuration > - Primary logs during a failover > - Backup logs during a failover > - Client pom.xml, application.properties & Java code > > Thanks in advance for your help. > > Best Regards, > Alexandre > > > ---------- Forwarded message --------- > From: Justin Bertram < [email protected] > > Date: Thu, 4 Sept 2025 at 20:57 > Subject: Re: Unable to handle failover in a Spring client with the CORE > protocol > To: < [email protected] > > > > Can you confirm that your cluster is forming properly and when the primary > is stopped the backup activates? > > Do you have details on the specific exception that the client is seeing? > > Can you provide the actual, full URL that you're using (i.e. with the > properties expanded/replaced)? > > Lastly, can you confirm that the XML you pasted is, in fact, from your > primary node? It looks to me like it's from the backup. > > > Justin > > On Thu, Sep 4, 2025 at 10:40 AM < [email protected] .invalid> > wrote: > > > Hello, > > I'm currently trying to set up a Spring Artemis client and particularly > > the failover mechanism. > > > > I sat up Artemis using a cluster two nodes replicated using a static > > definition: > > > > Below my primary node configuration (from the broker.xml file) > > > > <cluster-user>USER</cluster-user> > > <cluster-password>PASSWORD</cluster-password> > > <ha-policy> > > <replication> > > <backup> > > <allow-failback>true</allow-failback> > > </backup> > > </replication> > > </ha-policy> > > <connectors> > > <connector name="backup">tcp://artemis-backup:61616</connector> > > <connector name="primary">tcp://artemis-primary:61616</connector> > > </connectors> > > <acceptors> > > <acceptor name="artemis">tcp:// 0.0.0.0:61616?protocols=OPENWIRE,CORE > > </acceptor> > > </acceptors> > > > > <cluster-connections> > > <cluster-connection name="my-cluster"> > > <connector-ref>backup</connector-ref> > > <static-connectors> > > <connector-ref>primary</connector-ref> > > </static-connectors> > > <retry-interval>1000</retry-interval> > > <use-duplicate-detection>true</use-duplicate-detection> > > </cluster-connection> > > </cluster-connections> > > > > > > On the client side, I use Spring Boot & the artemis starter > > > > <dependency> > > <groupId>org.springframework.boot</groupId> > > <artifactId>spring-boot-starter-artemis</artifactId> > > </dependency> > > > > and configured the properties as following: > > > > > > > spring.artemis.broker-url=(${ARTEMIS_PRIMARY_URL}?name=primary,${ARTEMIS_BACKUP_URL}?name=backup)?protocol=CORE&ha=true&reconnectAttempts=1000&failoverAttempts=1000&clientFailureCheckPeriod=30000 > > > spring.artemis.user=USER > > spring.artemis.password=PASSSWORD > > spring.artemis.mode=native > > > > Unfortunately, when I run several write/read calls using the > JMSTemplate, > > it fails when the primary node stops and the backup node takes over it. > An > > exception is automatically raised and the client doesn't automatically > > shift to the backup server on the fly. > > Otherwise, when I re-try my request, it's OK. > > > > When I try to do the same with the OPENWIRE protocol and the failover > URL, > > it works. During the same thread, the failover is perfectly handled. > > > > How can I get the same behaviour with the CORE protocol? > > > > Thanks in advance. > > > > Best Regards, > > Alexandre > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > For further information, visit: https://activemq.apache.org/contact > > > > > > > > > > > > > Alexandre Touret > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > For further information, visit: https://activemq.apache.org/contact > > >
