It should be safe to reduce these timeouts to more realistic durations machine-wide unless you have systems that actually depend on the unusually long retransmits.Īn additional approach is using the ForceReconnect pattern recommended in the Azure best practices. In addition to tcp_retries2, you can try tuning the keepalive settings as discussed here: lettuce-io/lettuce-core#1428 (comment). If the client gave up and created a NEW connection, it would be able to resume communication with the server much sooner than 15 minutes.Īs you found, there are TCP settings you can change on the client machine to force it to timeout the connection sooner and allow for reconnect. Even when the node has rebooted and come back, it has no record of that connection so it continues ignoring the client. The client TCP stack continues retransmitting on the same socket hoping the server will come back up. In this case, the machine goes down abruptly and the Redis server isn't able to transmit a FIN packet to the client. With Azure Cache for Redis, it's fairly easy to reproduce this by rebooting nodes as mentioned above. When a server stops responding without gracefully closing the connection, the client TCP stack will continue retransmitting packets for 15 minutes before declaring the connection dead and allowing the StackExchange.Redis reconnect logic to kick in. Should the Best Practice be to call ForceReconnect on TimeoutExceptions when running on Linux and also when you encounter RedisConnectionExceptions?Ĭonnection stalls lasting for 15 minutes like this are often caused by very optimistic default TCP settings in some Linux distros (confirmed on CentOS so far).Are there Best Practice TCP Settings that should be used when running on Linux?.Is this something that can be handled or improved in the StackExchange.Redis library?.In this situation, when the application is running on Linux it throws TimeoutExceptions, which the documentation says do not call the ForceReconnect code.The documentation also says,ĭon't call ForceReconnect for Timeouts, just for RedisConnectionExceptions or SocketExceptions Following the Best Practices guide, you should be implementing a ForceReconnect method to handle these types of scenarios.Updating the setting did not have any impact when the application reconnected. Installing Docker on the Linux server, updating the sysctl setting _retries2 to 5 and running the application as a container did not reconnect quickly.The downside to making this change is that it is a TCP setting for the server and if have multiple applications running on that server, they are all affected. Lowering this setting to '5', I found that the application threw the correct type of errors and reconnected approximately 1 minute after the nodes went down. This setting decides the total time before a connection failure is declared.
#Pctv systems client conexão perdida update#
When running on a Linux server you can update the sysctl setting _retries2.
: Timeout awaiting response (outbound=0KiB, inbound=0KiB, 5570ms elapsed, timeout is 5000ms), command=SET, next: SET FAO1X, inst: 0, qu: 0, qs: 12, aw: False, rs: ReadAsync, ws: Idle, in: 0, serverEndpoint. The application throws TimeoutExceptions and does not reconnect for 15 minutes. End of stack trace from previous location. End of inner exception stack trace -Īt (TaskCompletionSource`1 source, Exception unthrownException) in /_/src/StackExchange.Redis/ConnectionMultiplexer.cs:line 2802 There was an authentication failure check that passwords (or client certificates) are configured correctly. > : It was not possible to connect to the redis server(s). : No connection is active/available to service this operation: SET N4BDN It was not possible to connect to the redis server(s).
0 kommentar(er)
