Reduce the log level of validateObject to WARN

[sazzad16]

There have been confusions, misunderstandings, half-understandings regarding ERROR logs in JedisFactory#validateObject and ConnectionFactor#validateObject.

Here is a list of relevant concerns:

• [Suggested change] Log a warning when ConnectionFactory.validateObject determines the connection is no longer connected and/or the ping fails #3748
• redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stream. - issue with jedis 5.1.0 #3723
• jedis 4.3.0 error while validaing pooled connection object #3314
• "commons-pool-evictor" randomly throws "Unexpected end of stream.". #3106
• Random Unexpected end of stream when sending a command #3100 (comment)
• NOAUTH Authentication required #3067
• Not able to catch Exception when validating #2712

I think, reducing the log level to WARN would resolve or at least reduce these concerns to some extent.

[sazzad16]

@yangbodong22011 @dengliming

[yangbodong22011]

I think general business will configure the level of info. There seems to be no difference between error or warn (both will be printed). Maybe we should consider debug?

[kdrakon]

I think general business will configure the level of info. There seems to be no difference between error or warn (both will be printed). Maybe we should consider debug?

Both would be printed, but having them at specific levels means setting up alerts based on the level (eg Datadog, Pagerduty, etc) is possible. For example, we only trigger alerts for on-call when the level is ERROR, meaning something catastrophic, possibly unrecoverable, has happened. Since most people don't log production applications at the DEBUG level, those logs would be unseen.

[sazzad16]

The thing is we wanted those to be seen so that users can take actions. Sometimes its just network, sometimes tweaking Jedis/Redis configs were enough to improve the health/performance of the application.

IMO, we now go to WARN. Depending on the feedback/reaction, we'll consider DEBUG.

[kdrakon]

Is there any reason this was leapfrogged and not included in release https://github.com/redis/jedis/releases/tag/v5.1.2?

[sazzad16]

@kdrakon This has breaking implication. Some applications may be dependant on the logs, but they will miss out if their log level is set to ERROR. So this change is not part of a patch release and will be part of 5.2.0. If you really want, this change is available in 5.2.0-SNAPSHOT.