Created Jira https://issues.apache.org/jira/browse/AMQ-9569
On 04.09.2024 20:32, Martin Lichtin wrote:
We often encounter this call stack, with the suspicion that the thread
forever hangs in the socket read:
"ActiveMQ Task-5" #195869202 daemon prio=5 os_prio=0
tid=0x00007f8b68090000 nid=0xe591 runnable [0x00007f8a7f4eb000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at
sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:464)
at
sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at sun.security.ssl.SSLTransport.decode(SSLTransport.java:109)
at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1401)
at
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1309)
at
sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:440)
at
sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:822)
at sun.security.ssl.SSLSocketImpl.access$200(SSLSocketImpl.java:73)
at
sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:1184)
at
org.apache.activemq.transport.tcp.TcpBufferedOutputStream.flush(TcpBufferedOutputStream.java:115)
at java.io.DataOutputStream.flush(DataOutputStream.java:123)
at
org.apache.activemq.transport.tcp.TcpTransport.oneway(TcpTransport.java:194)
at
org.apache.activemq.transport.AbstractInactivityMonitor.doOnewaySend(AbstractInactivityMonitor.java:335)
at
org.apache.activemq.transport.AbstractInactivityMonitor.oneway(AbstractInactivityMonitor.java:317)
at
org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:181)
at
org.apache.activemq.transport.WireFormatNegotiator.sendWireFormat(WireFormatNegotiator.java:84)
at
org.apache.activemq.transport.WireFormatNegotiator.start(WireFormatNegotiator.java:74)
at
org.apache.activemq.transport.TransportFilter.start(TransportFilter.java:64)
at
org.apache.activemq.transport.WriteTimeoutFilter.start(WriteTimeoutFilter.java:132)
at
org.apache.activemq.transport.failover.FailoverTransport.doReconnect(FailoverTransport.java:1026)
- locked <0x00000006caf036c0> (a java.lang.Object)
at
org.apache.activemq.transport.failover.FailoverTransport$2.iterate(FailoverTransport.java:151)
- locked <0x00000006cb402778> (a java.lang.Object)
at
org.apache.activemq.thread.PooledTaskRunner.runTask(PooledTaskRunner.java:133)
at
org.apache.activemq.thread.PooledTaskRunner$1.run(PooledTaskRunner.java:48)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:750)
soWriteTimeout is set to 5000, so the "WriteTimeoutFilter" should do
its thing.
However, and this feels slightly weird, looking at WriteTimeoutFilter,
is this oneway() registering and instantly de-registering?
@Override
public void oneway(Object command) throws IOException {
try {
registerWrite(this);
super.oneway(command);
} catch (IOException x) {
throw x;
} finally {
deRegisterWrite(this,false,null);
}
}
shouldn't perhaps the registerWrite() be called from the start()
method, and the deRegisterWrite() done in the stop() method?
I continue debugging, but wanted to reach out in case I'm on the wrong
path, or on to something
- Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org
For additional commands, e-mail: users-h...@activemq.apache.org
For further information, visit: https://activemq.apache.org/contact
