Thanks for your answer, Darrel. If the breaking change is not a viable option, how about at least having both clients agree on the -1 value (currently -1 is not supported by the native client) to mean never idle expire and never load condition respectively?
It is true that they will not agree on the 0 value but at least they would agree on -1. Not sure if this compromise change will really be for the better. Alberto ________________________________ From: Darrel Schneider <dar...@vmware.com.INVALID> Sent: Monday, June 13, 2022 10:03 PM To: dev@geode.apache.org <dev@geode.apache.org> Subject: Re: [DISCUSS] Alignment of values disabling idleTimeout/loadConditioningInterval between Geode client APIs My concern is you are proposing to change the behavior of an existing geode feature. I think 0 is currently supported for both these properties in the Java client. I would think they cause immediate idle expiration and a very hot load conditioning. Your proposal would make 0 mean something very different (never idle expire and never load condition). Also since both of these properties express a time duration, interpreting the value 0 as a very short duration is the natural meaning. Treating as an infinite duration takes some explanation. If the native client currently does not support setting these properties to -1 then you could more safely change it to treat -1 as an infinite duration like the Java client does. So at least both clients would agree on what -1 means. But they would still disagree on what 0 means. To bring them into agreement you need to make a breaking change in either the native client or the java client. It might be best just to document this difference. I think it might be a small subset of our user base that thinks everything on the native client will be consistent with the Java client. Or vice versa. I think most users of one client do not even use the other client. ________________________________ From: Alberto Gomez <alberto.go...@est.tech> Sent: Monday, June 13, 2022 8:20 AM To: dev@geode.apache.org <dev@geode.apache.org> Subject: [DISCUSS] Alignment of values disabling idleTimeout/loadConditioningInterval between Geode client APIs ⚠ External Email 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fclient%2FPoolFactory.html%23setIdleTimeout-long-&data=05%7C01%7Cdarrel%40vmware.com%7C8d31f0e0512b45f215da08da4d5099a9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907305827807591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=9Lw0czqIngj47SoJM5hJZJxojAcJjqh3OPYescN4Ctg%3D&reserved=0 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fcppdocs%2Fa00799.html%23ae5fef0b20d95f11399a1fa66f90fbc74&data=05%7C01%7Cdarrel%40vmware.com%7C8d31f0e0512b45f215da08da4d5099a9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907305827807591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pOzqVhNF1WRj3XYqvM%2BUCcwSTLRc94xaCclBvr5X1t8%3D&reserved=0 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fjavadoc%2Forg%2Fapache%2Fgeode%2Fcache%2Fclient%2FPoolFactory.html%23setLoadConditioningInterval-int-&data=05%7C01%7Cdarrel%40vmware.com%7C8d31f0e0512b45f215da08da4d5099a9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907305827807591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bbn6PVstkE9P6ZOcVUZW4%2FJTXrDEIY1UMNJEzq9Oq40%3D&reserved=0 Nevertheless, according to the documentation of the Geode Native client API, setting a value of std::chrono::milliseconds::zero() disables load conditioning. https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgeode.apache.org%2Freleases%2Flatest%2Fcppdocs%2Fa00799.html%23aaa812743d8458017bdbb8afa144c05e7&data=05%7C01%7Cdarrel%40vmware.com%7C8d31f0e0512b45f215da08da4d5099a9%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907305827807591%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zUQDeM%2FkwiTjG9WzHp0t3FPqPt48HuFkYvTpLDnSyWk%3D&reserved=0 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 ________________________________ ⚠ External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
