Hello!

I'm using Artemis as an embedded server, so I want to disable all connection ttl checking. To do so I set connection ttl to -1 for Client Connection Factory. But from time to time I got messages like these in log

647236 [WARN] client: AMQ212037: Connection failure has been detected: AMQ119014: Did not receive data from invm:0 within the -1ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
....
647256 [ERROR] ClientSessionImpl: ActiveMQUnBlockedException[errorType=UNBLOCKED message=AMQ119016: Connection failure detected. Unblocking a blocking call that will never get a response] org.apache.activemq.artemis.api.core.ActiveMQUnBlockedException: AMQ119016: Connection failure detected. Unblocking a blocking call that will never get a response     at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:409) ~[artemis-core-client-2.1.0.1.jar:2.1.0.1]     at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155) [surefire-booter-2.18.1.jar:2.18.1]     at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103) [surefire-booter-2.18.1.jar:2.18.1]
........
Caused by: org.apache.activemq.artemis.api.core.ActiveMQNotConnectedException: AMQ119006: Channel disconnected     at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.connectionDestroyed(ClientSessionFactoryImpl.java:353) ~[artemis-core-client-2.1.0.1.jar:2.1.0.1]

I made some research and found org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl.FailureCheckAndFlushThread. It looks like RemotingServiceImpl has it's own connection ttl and check interval. And in the end I didn't find any relation between client's connection ttl and RemotingServiceImpl's connection ttl.

So, can I somehow disable connection checking on server? What are these ttl settings (client and server), that seem irrelevant, exactly for?

Maybe I'm wrong and this is something different, completely not related to ttl checking?


Thanks,

Denis

Reply via email to