To avoid thread execution for too long, we interrupt the thread after the time limit is reached. Recently, We find that occasionally messages get lost. We use TX mode , and txCommit() got an ChannelContinuationTimeoutException. I found the following problem according to the warning log.
if thread interrupted before rpc(m,k) then rpc will not be sent to the server. And k.getReply(..) will hang for _rpcTimeout or forever.
client version is 5.8.0
com.rabbitmq.client.impl.AMQChannel
private AMQCommand privateRpc(Method m)
throws IOException, ShutdownSignalException
{
SimpleBlockingRpcContinuation k = new SimpleBlockingRpcContinuation(m);
rpc(m, k);
// At this point, the request method has been sent, and we
// should wait for the reply to arrive.
//
// Calling getReply() on the continuation puts us to sleep
// until the connection's reader-thread throws the reply over
// the fence or the RPC times out (if enabled)
if(_rpcTimeout == NO_RPC_TIMEOUT) {
return k.getReply();
} else {
try {
return k.getReply(_rpcTimeout);
} catch (TimeoutException e) {
throw wrapTimeoutException(m, e);
}
}
}
To avoid thread execution for too long, we interrupt the thread after the time limit is reached. Recently, We find that occasionally messages get lost. We use TX mode , and txCommit() got an ChannelContinuationTimeoutException. I found the following problem according to the warning log.
if thread interrupted before rpc(m,k) then rpc will not be sent to the server. And k.getReply(..) will hang for _rpcTimeout or forever.
client version is 5.8.0