Auto reconnect do not work if command timeout · Issue #1727 · redis/lettuce · GitHub |
您所在的位置：网站首页 › ReconnectionHandler › Auto reconnect do not work if command timeout · Issue #1727 · redis/lettuce · GitHub |
|
@mp911de I'm having a similar issue as @aamrute-idnow where it appears that lettuce is sometimes having problems reconnecting to the server after a connection is closed. The client application will have problems for ~ 10 min and then finally reconnect to the server (during that period all commands except for PING will timeout). In my case, I know why the connection is being closed - it's because our server has timeout 300 in redis.conf which will close the connection after a client is idle for 300 seconds. Our client application sits idle most of the day but runs batches of work at night. I'm using lettuce-core : 6.0.4.RELEASE and our server is version 5.0.6 - I'm happy to share more / provide logs etc. Right now I'm working to repeat this on my local machine but so far not having a ton of luck. Below is what the stack trace looks like when the connection is closed by the server after 300 seconds of idle time. INFO - io.lettuce.core.protocol.CommandHandler : [channel=0x47606e1c, /127.0.0.1:58198 -> localhost/127.0.0.1:6379, chid=0x8] Unexpected exception during request: java.io.IOException: An existing connection was forcibly closed by the remote host java.io.IOException: An existing connection was forcibly closed by the remote host at sun.nio.ch.SocketDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:192) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:377) at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253) at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132) at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151) at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719) at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655) at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581) at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493) at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989) at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) at java.lang.Thread.run(Thread.java:748)EDIT: one thing I have observed is that all of the PING commands return successfully (we have pingBeforeActivateConnection set to true) even while all of the other commands like GET / SET / INFO timeout. We have the following settings in our client application: spring: redis: connect-timeout: PT0.3S timeout: PT0.5S |
| CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |