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.
