> 1- Should we be setting connectionFactory.setConfirmationWindowSize()?
The docs for confirmationWindowSize are here [1]. Whether you should set this parameter is really up to you and the behavior you want for your application. > 2- Are the retry settings reasonable? "Reasonable" is hard to judge in a support context like this. I'm not sure we can really judge. > Ultimately we just want to reconnect in under a minute and avoid our timeout. It might be worth investigating why you got the timeout in the first place. Do you have any data from the broker or the network that might suggest what happened? > Or, maybe we just need to set our timeout longer? Without knowing the root cause of the timeout it's impossible to say. Justin [1] https://activemq.apache.org/components/artemis/documentation/latest/client-failover.html#reconnect-to-the-same-server On Tue, Nov 19, 2024 at 3:30 PM John Lilley <john.lil...@redpointglobal.com> wrote: > 2024-11-19 14:19:51,426 WARN [org.apache.activemq.artemis.core.server] > AMQ222066: Reattach request from 10.147.133.72:53082 failed as there is > no confirmationWindowSize configured, which may be ok for your system > > This was issued by the broker at the same time that our JMS client issued > this warning: > > 2024-11-19T14:19:51.417 [Thread-2 (ActiveMQ-client-global-threads)] > .client.connectionFailureDetected:293 [] WARN - AMQ212037: Connection > failure to dm-activemq-live-svc/10.0.219.91:61616 has been detected: > AMQ219014: Timed out after waiting 10000 ms for response when sending > packet 71 [code=CONNECTION_TIMEDOUT] > 2024-11-19T14:19:51.414 [main] .JmsProducerPool.send_:389 [y6y5v5wm1s0x] > WARN - Error sending message, will retry jakarta.jms.JMSException: > AMQ219014: Timed out after waiting 10000 ms for response when sending > packet 71 > at > org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:550) > at > org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:452) > at > org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.sendFullMessage(ActiveMQSessionContext.java:588) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.sendRegularMessage(ClientProducerImpl.java:305) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.doSend(ClientProducerImpl.java:277) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:147) > at > org.apache.activemq.artemis.core.client.impl.ClientProducerImpl.send(ClientProducerImpl.java:129) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.doSendx(ActiveMQMessageProducer.java:483) > at > org.apache.activemq.artemis.jms.client.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:221) > at > net.redpoint.rpdm.ipc.jms.JmsProducerPool.send_(JmsProducerPool.java:385) > at > net.redpoint.rpdm.ipc.jms.JmsProducerPool.sendRequest(JmsProducerPool.java:300) > at > net.redpoint.rpdm.ipc.jms.JmsRpcClientChannel.sendRequest(JmsRpcClientChannel.java:230) > at > net.redpoint.rpdm.ipc.jms.JmsRpcClientChannel.invokeRaw(JmsRpcClientChannel.java:203) > Caused by: > ActiveMQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT > message=AMQ219014: Timed out after waiting 10000 ms for response when > sending packet 71] > ... 13 more > > After 72 seconds, we hit our own 60-second timeout and fail. > > In our connection factory, we are setting > > connectionFactory.setRetryInterval(1000); > connectionFactory.setRetryIntervalMultiplier(1.5); > connectionFactory.setMaxRetryInterval(4000); > > > So my questions are: > 1- Should we be setting connectionFactory.setConfirmationWindowSize()? > 2- Are the retry settings reasonable? > > Ultimately we just want to reconnect in under a minute and avoid our > timeout. Or, maybe we just need to set our timeout longer? > > Our maven dependency for the JMS driver: > <dependency> > <groupId>org.apache.activemq</groupId> > <artifactId>artemis-jakarta-client</artifactId> > <version>2.32.0</version> > </dependency> > > Please advise. > Thanks > John > > PLEASE NOTE: This e-mail from Redpoint Global Inc. ("Redpoint") is > confidential and is intended solely for the use of the individual(s) to > whom it is addressed. If you believe you received this e-mail in error, > please notify the sender immediately, delete the e-mail from your computer > and do not copy, print or disclose it to anyone else. If you properly > received this e-mail as a customer, partner or vendor of Redpoint, you > should maintain its contents in confidence subject to the terms and > conditions of your agreement(s) with Redpoint. >
