Affects: org.springframework:spring-jms:5.3.14

Setup

  • Service with Spring Version 5.3.14
  • ActiveMQ mq.t3.micro with no free space
  • application.config:
  activemq:
    broker-url: failover:(ssl://<someURL>:61617,ssl://<someURL>:61617)?randomize=true&maxReconnectAttempts=1&startupMaxReconnectAttempts=1&maxReconnectDelay=2000
    user:<someUser>
    password: <somePassword>
    send-timeout: 3000
    pool:
      enabled: true
      max-connections: 20
  jms:
    template:
      qos-enabled: true
      time-to-live: 86400000
    pub-sub-domain: true
    cache:
      enabled: false

Expected behavior

If the method public void send(final String destinationName, final MessageCreator messageCreator) throws JmsException in the JmsTemplate class is executed, the maximum running time is as in send-timeout configured, about 3 seconds.

Observed behavior

We see some calls that go up to 5 minutes in execution time, when this jms method is called.

It is interesting, however, as soon as a TCP connection to the MQ is established, the 3 seconds are running out and the Lib then throws a timeout as expected org.apache.activemq.transport.RequestTimedOutIOException the activemq log does not contain any useful information. The only warnings we see are:

2022-03-02 06:58:12,093 | WARN | Transport Connection to: tcp://<someIP>:40600 failed | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ InactivityMonitor Worker
java.net.SocketException: Connection reset
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:115)[:1.8.0_322]
at java.net.SocketOutputStream.write(SocketOutputStream.java:155)[:1.8.0_322]
at sun.security.ssl.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:319)[:1.8.0_322]
at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1214)[:1.8.0_322]
at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)[activemq-client-5.15.15.jar:5.15.15]
at java.io.DataOutputStream.flush(DataOutputStream.java:123)[:1.8.0_322]
at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194)[activemq-client-5.15.15.jar:5.15.15]
at org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:335)[activemq-client-5.15.15.jar:5.15.15]
at org.apache.activemq.transport.AbstractInactivityMonitor.access$800(AbstractInactivityMonitor.java:42)[activemq-client-5.15.15.jar:5.15.15]
at org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:201)[activemq-client-5.15.15.jar:5.15.15]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_322]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_322]
at java.lang.Thread.run(Thread.java:750)[:1.8.0_322]

2022-03-02 06:58:12,093 | WARN | Transport Connection to: tcp://<someIP>:40600 failed | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ InactivityMonitor Worker java.net.SocketException: Connection reset at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:115)[:1.8.0_322] at java.net.SocketOutputStream.write(SocketOutputStream.java:155)[:1.8.0_322] at sun.security.ssl.SSLSocketOutputRecord.deliver(SSLSocketOutputRecord.java:319)[:1.8.0_322] at sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1214)[:1.8.0_322] at org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)[activemq-client-5.15.15.jar:5.15.15] at java.io.DataOutputStream.flush(DataOutputStream.java:123)[:1.8.0_322] at org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194)[activemq-client-5.15.15.jar:5.15.15] at org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:335)[activemq-client-5.15.15.jar:5.15.15] at org.apache.activemq.transport.AbstractInactivityMonitor.access$800(AbstractInactivityMonitor.java:42)[activemq-client-5.15.15.jar:5.15.15] at org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:201)[activemq-client-5.15.15.jar:5.15.15] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)[:1.8.0_322] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)[:1.8.0_322] at java.lang.Thread.run(Thread.java:750)[:1.8.0_322]

However, we could not determine any temporal connection between these warnings and the behavior that occurred. In our application are also no debug logs which could help us to identify the root cause.

Conclusion

There seems to be something in the send messag methode, that in some cases is taking too much time, till it starts to connect to the ActiveMQ

Edit: There seems to be a connection to failover of an mq. We could observe the same behavior when we changed our broker's configuration (disable multi-A-Z).

Thank you in advance for your help. :)

Comment From: snicoll

There seems to be a connection to failover of an mq. We could observe the same behavior when we changed our broker's configuration (disable multi-A-Z).

If you can observe such difference in behavior by changing the configuration of the broker, that looks like a broker problem to me. If you feel differently, please share a small sample that we can run ourselves to reproduce the problem as I am afraid a config snippet is not enough. You can attach a zip to this issue or push the code to a separate GitHub repository.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: spring-projects-issues

Closing due to lack of requested feedback. If you would like us to look at this issue, please provide the requested information and we will re-open the issue.