springboot整合redis一直报远程主机强迫关闭了一个现有的连接

九转成圣

发布于 2024-05-08 08:15:52

3430

发布于 2024-05-08 08:15:52

文章被收录于专栏：csdn

springboot整合redis一直报远程主机强迫关闭了一个现有的连接

问题描述

2024-04-28 06:54:20 - INFO - [oEventLoop-4-7] io.lettuce.core.protocol.CommandHandler .          log 219 : null Unexpected exception during request: java.io.IOException: 远程主机强迫关闭了一个现有的连接。

java.io.IOException: 远程主机强迫关闭了一个现有的连接。
	at sun.nio.ch.SocketDispatcher.read0(Native Method) ~[na:1.8.0_201]
	at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) ~[na:1.8.0_201]
	at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) ~[na:1.8.0_201]
	at sun.nio.ch.IOUtil.read(IOUtil.java:192) ~[na:1.8.0_201]
	at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) ~[na:1.8.0_201]
	at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:247) ~[netty-buffer-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1147) ~[netty-buffer-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350) ~[netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:148) ~[netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:700) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:635) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:552) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:514) [netty-transport-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1050) [netty-common-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74) [netty-common-4.1.43.Final.jar:4.1.43.Final]
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30) [netty-common-4.1.43.Final.jar:4.1.43.Final]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_201]

修改配置文件

需要修改一下2处,好像timeout 默认就是0,tcp-keepalive默认就是300,那为什么还回报错呢?可能是启动的时候没有指定配置文件

当一个客户端空闲N秒后关闭连接（0表示禁用）

119 # Close the connection after a client is idle for N seconds (0 to disable)
120 timeout 0

如果非0每隔配置的时间就给客户端发送ack,这么做有两个原因(简言之一个是探活,另一个是保持链接)

检测死亡的对等体(客户端):就是给客户端发送ack请求,如果客户端死了就收不到来自客户端的回复,此时redis服务就会清掉这个客户端的链接.
强制中间的网络设备认为连接是活动的。在 Redis 客户端和服务器之间，可能会存在多个中间网络设备，例如路由器、交换机等等。这些设备可能会对连接进行优化或者限制。如果一个连接在一段时间内没有数据传输，这些设备可能会认为这个连接已经失效，从而关闭连接或者释放资源。使用 TCP keepalive 可以让 Redis 服务器定期向客户端发送 TCP ACKs，以确保连接处于活动状态。这样，中间的网络设备会认为连接是活动的，并且不会关闭连接或者释放资源。这可以提高连接的稳定性和可靠性，避免连接被意外关闭。

in absence of communication怎么理解???chatgpt给出的解释是"如果客户端暂停发送请求或者网络中断了,Redis服务端也会给客户端发送ack"

 122 # TCP keepalive.
 123 #
 124 # If non-zero, use SO_KEEPALIVE to send TCP ACKs to clients in absence
 125 # of communication. This is useful for two reasons:
 126 #
 127 # 1) Detect dead peers.
 128 # 2) Force network equipment in the middle to consider the connection to be
 129 #    alive.
 130 #
 131 # On Linux, the specified value (in seconds) is the period used to send ACKs.
 132 # Note that to close the connection the double of the time is needed.
 133 # On other kernels the period depends on the kernel configuration.
 134 #
 135 # A reasonable value for this option is 300 seconds, which is the new
 136 # Redis default starting with Redis 3.2.1.
 137 tcp-keepalive 300

重启redis服务

本文参与腾讯云自媒体同步曝光计划，分享自作者个人站点/博客。

原始发表：2024-05-07，如有侵权请联系 cloudcommunity@tencent.com 删除

netty