I have raised this issue a few times. All over our API we are inconsistent with time. Either in the use of sentinel values or time units. Given the current API and breaking that is not an option until some major release the best thing you can do is not use the sentinel values. If you want something to “wait forever” set the time to the maximum value, in many cases this is longer than many of us will be live, let alone how long the system will stay online or reasonably wait for an event.
I would like to see us add new APIs that take strong typed time values for things the have timeouts, no time values if the method should wait forever, and “try” prefix for things that should try but never wait. Internally I strongly suggest we do away with “forever” as a concept and forward all forever blocking calls to the timeout version of the method with the max timeout value and unit, effectively forever. -Jake On Jun 14, 2022, at 3:12 AM, Alberto Gomez <alberto.go...@est.tech<mailto:alberto.go...@est.tech>> wrote: ⚠ External Email 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<mailto:dar...@vmware.com.INVALID>> Sent: Monday, June 13, 2022 10:03 PM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto: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<mailto:alberto.go...@est.tech>> Sent: Monday, June 13, 2022 8:20 AM To: dev@geode.apache.org<mailto:dev@geode.apache.org> <dev@geode.apache.org<mailto: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%7Cjabarrett%40vmware.com%7Cea4c426f777a4439a37d08da4dee6b31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907983650611670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ACne8eenRyT2G1R4uwKO8CfNS3Zh1IYFi5N%2BzhsG0x8%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%7Cjabarrett%40vmware.com%7Cea4c426f777a4439a37d08da4dee6b31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907983650611670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=c%2BsEdq6Cp8JGgWf6R8Q8keQXPrUiUS0S0rVtrfczuYc%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%7Cjabarrett%40vmware.com%7Cea4c426f777a4439a37d08da4dee6b31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907983650611670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Nu%2BnUcI0FARfyfNLy3OoHFoUI6rOcqTsQOXEL7tXxr0%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%7Cjabarrett%40vmware.com%7Cea4c426f777a4439a37d08da4dee6b31%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637907983650611670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hVfU%2BZbfJQRkmmA42tYXd3my9ylUCZ55KARpdKX0FjM%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.
