Hello Matt. Perhaps you've seen my last mail where I said that "failover" and "keepAlice" do not fix my "consumer is closed"... I've also joined my pax configuration.
I've reduced my Camel application to get only one consumer. Now logs are simpler, and I can see that the unique consumer on a queue fails every 30 minutes. I've looked at the transport option, and I can't identify any parameter that could be related to such a period of 30 minutes. Any ideas ? I'm going to check with my K8s experts if they know some kind of cluster's configuration that may lead to a 30 minutes system operation... Thanks again. Regards. Le lun. 10 juil. 2023 à 18:27, Matt Pavlovich <mattr...@gmail.com> a écrit : > > Hi Ephemeris- > > 1. Yes, you should use failover:() even with one URL (esp if using load > balancer) > > 2. These Camel errors are trick to troubleshoot without seeing all the > settings. Camel JMS uses Spring JMS under the covers, and understanding how > that works in combination with Connection Pooling is tricky. Specifically— > setting the max pooled objects is _not_ the same as max connections. Pooled > objects may include connections + sessions + consumers, depending on your > configuration. Setting that number to ’25’ may be too low. If your used > connections + sessions + consumers is 25 or higher. I think the default is > 500, so you are significantly lowering it. > > Adding more debug and add’l logging would be need to root cause. > > Also note, this level of debugging is beyond what is reasonable to expect > getting a resolution from ActiveMQ user mailing list and/or Stackoverflow > type developer support. > > Thanks, > Matt Pavlovich > > > On Jul 10, 2023, at 4:41 AM, Ephemeris Lappis <ephemeris.lap...@gmail.com> > > wrote: > > > > 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. > >> >
