Hello. Thanks for your answer.
Do you mean that even if we use a single instance we should use a failover protocol in our clients configurations like that : "failover:(tcp:activemq-service:61616)" ? Do you know if other connection options may actually help (keepAlive, useKeepAlive, ...) ? As we do not really understand what circumstances produce the exceptions, "blindly" setting misunderstood options does not appear a winning solution to problems that we've never had before. 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. >
