Hello again. Perhaps you've already seen my previous mail... I've tried some options and none of them seems to fix my connection issues.
I've tried first adding "failover" over my tcp URL, and then "keekAlice=true" on the tcp transport, and then the two changes together, and I have exactly the same errors. My connection factory configuration now is : # Connection configuration type=activemq connectionFactoryType=ConnectionFactory # Names name=alice-jms osgi.jndi.service.name=jms/alice # Connection factory properties jms.url=failover:(tcp://alice-echanges-activemq:61616?keepAlive=true) jms.user=alice jms.password=alice jms.clientIDPrefix=CATERPILLAR # Set XA transaction xa=false # Connection pooling pool=pooledjms # Maximum number of connections for each user+password (default 1) pool.maxConnections=256 # Maximum idle time in seconds (default 30 seconds) pool.connectionIdleTimeout=30 # Interval for connections idle time checking in milliseconds (default 0 for none) pool.connectionCheckInterval=15000 Except the URL that I changed as explained before, this is the same configuration that we have been using for a long time either between VMs, or between docker containers in compose, or between containers and VM... We've never observed this kind of errors before, and our K8s experts do not explain what my be different in the cluster environment that could be the origin of the issue... More ideas from similar experiences ? Thanks again. Regards. Le ven. 7 juil. 2023 à 18:21, Matt Pavlovich <mattr...@gmail.com> a écrit : > > Hi Ephermeris- > > Recommendations when running in the cloud is to be sure to enable a lot of > self-healing features. Networking (esp in kubernetes) can be inconsistent > when compared to local developer desktop. > > 1. Use failover:( .. ) transport in client urls > 2. Use PooledConnectionFactory (esp w/ Camel) > 3. Configure PooledConnectionFactory to expire connections > 4. If possible, add a scheduled task to your Camel routes to periodically > restart these routes (this releases connections and allows new connections to > spin up) > 5. Look into using camel-sjms vs the Spring JMS-based component to see if its > a better fit > > Thanks, > -Matt > > > On Jul 7, 2023, at 10:47 AM, Ephemeris Lappis <ephemeris.lap...@gmail.com> > > wrote: > > > > Hello. > > > > We observe strange messages in our logs about ActiveMQ consumers. > > > > 17:33:29.684 WARN [Camel (XXXX_context) thread #452 - > > JmsConsumer[xxxx.internal.queue]] Setup of JMS message listener > > invoker failed for destination 'xxxx.internal.queue' - trying to > > recover. Cause: The Consumer is closed > > > > This message comes from Camel routes executed in Karaf. Similar > > messages are produced by consumers in SpringBoot applications. > > > > These WARN messages seem not to be always related to real issues, but > > sometimes application activities have failed after these logs > > appeared, and a restart of the clients have been required to restore a > > correct behavior. > > > > We have only seen that on a full Kubernetes configuration where both > > the ActiveMQ server and its clients (Camel/Kafaf or SpringBoot > > applications) run in the same namespace as distinct pods using a k8s > > service to join the openwire endpoint. > > > > Similar configurations with ActiveMQ or Karaf executed in docker > > containers or VM have never led to messages of this kind. > > > > So, what is the real meaning of this message whose conditions I can't > > identify ? > > > > Did someone already experience this behavior, in Kubernetes or not, ? > > > > Thanks in advance. > > > > Regards. >
