CLIENT-1772 client configurations changes, reasons?

Client Libraries Java Client
1

Hello

Migrating from 6.0.x I’d like to ask the rationale behind CLIENT-1772 ? Default values have been changed without explanation in the commit.

I found no JIRA or Bugzilla for the key CLIENT-1772. Are the discussions about commits available publicly ?

Thanks

2

Client configuration defaults were changed after internal stress testing and observations of difficulties encountered by new users.

  1. Set ClientPolicy maxConnsPerNode from 300 to 100.
  2. Set ClientPolicy asyncMaxConnsPerNode from 300 to 100 via defaulting to maxConnsPerNode.

There are been many cases where applications have unnecessarily exhausted practical OS socket capacity on client and/or server machines. Testing revealed that a smaller number of connections can still maintain similar performance levels in common scenarios. Large capacity deployments can always increase this value as necessary.

  1. Set ClientPolicy maxSocketIdle from 55 to 0 secs.

The original purpose of maxSocketIdle was to prevent the client from using a socket from the pool that was already closed by the server. Older 4.X servers closed sockets after 1 minute of inactivity. Newer servers use TCP keep-alive to detect inactive sockets and by default no longer close sockets after a fixed reap time.

The client maxSocketIdle default was changed to reflect this server change. See javadocs.

  1. Set ClientPolicy maxErrorRate from 0 to 100.

Stress testing revealed that clients can overwhelm a cluster with retries after node failures. maxErrorRate is a backoff mechanism that prevents the client from issuing commands after a specified number of errors in an errorRateWindow time frame. Specifying a maxErrorRate of 100 per node allowed clusters to survive node failures more efficiently. Old defaults caused clusters to be perform poorly (and sometimes fail).

  1. Set Policy totalTimeout from 0 to 1000 ms for all commands except scan/query.

Defaulting to no timeout for short-running commands can severely hinder performance (or hang) when those commands fail to complete and the application waits for completion before issuing new commands. The new java client totalTimeout default is also now consistent with the original C client totalTimeout default.

3 Likes
3

This topic was automatically closed 84 days after the last reply. New replies are no longer allowed.