Hello Stefan- No, this does not sound normal. The broker does not activate transportConnectors (for clients) or networkConnectors when in ’slave’ mode. Check the logs on the brokers to see what’s going on with the lock activation.
Note— you have to have a supported file system that supports correct distributed lock management (NFSv4, GFSv2, etc). File systems such as Windows SMB or CIFS shares do NOT handle locks properly. Thanks, Matt Pavlovich > On Jul 26, 2021, at 2:01 AM, Stefan Schotte > <sscho...@ra.rockwell.com.INVALID> wrote: > > Hi, > > I have the following configuration: > > > * Two actively running Tomcat instances running Apache Camel 2.20.2 that > use the competing consumer concept to read message of the same queue > * AMQ 5.15.0 in an Master Slave configuration using a shared kahaDB. > > > It happens that one of the Camel instances connects to the Slave Broker, even > though the slave broker is not active i.e. as far as I can tell (log files) > it did not get a lock on the kahaDB. > > When this occurs the route on that Camel Instance is blocked and we get a > ExchangeTimedOutException and this blocks the route and messages are being > queued up. > > WARN EndpointMessageListener:213 - Execution of JMS message listener failed. > Caused by: [org.apache.camel.RuntimeCamelException - > org.apache.camel.ExchangeTimedOutException: The OUT message was not received > within: 30000 millis. Exchange[ID-MXPBMES-01P-I02-1625784159041-1-16108]] > > > Is it normal that a slave broker accepts a connection from a client > application (Camel in our case) ? > > Thanks for the help. > > >
