The broker logs stop at 2025-09-05 06:44~46 while the exception in the
client app log is at 2025-09-05T07:22:39
2025-09-05T07:21:39.026Z INFO 1 --- [test-resilience] [global-threads)]
o.apache.activemq.artemis.core.client : AMQ214036: Connection closure to
artemis-primary/100.88.135.105:61616 has been detected: AMQ219015: The
connection was disconnected because of server shutdown [code=DISCONNECTED]
2025-09-05T07:22:39.216Z ERROR 1 --- [test-resilience] [nio-8080-exec-2]
o.a.c.c.C.[.[.[/].[dispatcherServlet] : Servlet.service() for servlet
[dispatcherServlet] in context with path [] threw exception [Request
processing failed: org.springframework.jms.UncategorizedJmsException:
Uncategorized exception occurred during JMS processing] with root cause
org.apache.activemq.artemis.api.core.ActiveMQConnectionTimedOutException:
AMQ219014: Timed out after waiting 30000 ms for response when sending
packet 45
at
org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:570)
~[artemis-core-client-2.40.0.jar:2.40.0]
Are the timestamps of the broker logs synced with the clist app?
Anyway, the stack trace indicates that the disconnection is after sending a
blocking message and before receiving the related response. The CORE
protocol cannot automatically handle this case because resending the
message could cause a duplication. The retry in this case must be handled
at the app level.
Regards,
Domenico
On Fri, 5 Sept 2025 at 10:33, <[email protected]> wrote:
> Sorry
> Here is the link:
>
> https://gist.github.com/alexandre-touret/016d0773320a3a71604506dfbd7ab0c8
>
> You could get the exception logs.
>
> Best Regards,
> Alexandre
>
> ----- Mail original -----
> De: "Domenico Francesco Bruscino" <[email protected]>
> À: [email protected]
> Envoyé: Vendredi 5 Septembre 2025 10:15:35
> Objet: Re: Unable to handle failover in a Spring client with the CORE
> protocol
>
> 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
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> For further information, visit: https://activemq.apache.org/contact
>
>
>
