Hi, According to the documentation of the Geode Java client API, setting -1 for idleTimeout in a Pool indicates that connections should never expire: https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/PoolFactory.html#setIdleTimeout-long-
Nevertheless, according to the documentation of the Geode Native client API, setting a duration of std::chrono::milliseconds::zero() for idleTimeout indicates that connections should never expire. https://geode.apache.org/releases/latest/cppdocs/a00799.html#ae5fef0b20d95f11399a1fa66f90fbc74 A similar discrepancy between the two clients can be observed for the loadConditioningInterval setting: According to the documentation of the Java client API, A value of -1 disables load conditioning: https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/PoolFactory.html#setLoadConditioningInterval-int- Nevertheless, according to the documentation of the Geode Native client API, setting a value of std::chrono::milliseconds::zero() disables load conditioning. https://geode.apache.org/releases/latest/cppdocs/a00799.html#aaa812743d8458017bdbb8afa144c05e7 This discrepancy can create confusion and lead to a misuse of the client APIs which can provoke an unexpected behavior in the client. Geode API clients should be consistent to avoid these types of problems. Therefore, I propose to align both client APIs to use the same values for disabling the timing out of connections due to idle-timeout and load-conditioning. Usually, alignment of the Java and native client consists of copying the behavior of the Java client into the C++ client. In this case, nevertheless, I think it makes more sense to take as the model the behavior of the native client. The reason is that I do not think it makes sense to support an idle-timeout and a load-conditioning-interval of 0 ms. Consequently, I think a logical value to disable both could be 0 ms. Any thoughts on this proposal? Thanks, Alberto
