Pavel, Thanks for sharing your thoughts. Right now I see that 2 reserved bytes come with every cache request: cacheId and flags. The first one is obvious, but the second one is used only for java thin client with enabled KeepBinary mode. I think we could use the flags byte and write an expiration policy flag when required. Whenever the server sees that there is a request with expiration flag, we deserialize a policy and apply it to the request.
From: Pavel Tupitsyn Sent: Friday, October 18, 2019 7:05 PM To: dev Subject: Re: Thin clients: WithExpiryPolicy Stateless approach looks a lot better to me. We have a choice: * Keep expiry policy on server and send an ID with every request (like a query cursor ID - 8 bytes) * Send full expiry policy with every expiry-enabled request (24 bytes - or maybe less? We should think about the format) Stateful approach will bring a lot of complexity if we consider Affinity Awareness [1] mechanism (and also automatic reconnect). We would have to keep ExpiryPolicyId for every server and choose the right one based on the affinity for every operation. This can easily negate any performance gain from saving 16 bytes. And there is always CacheConfiguration.ExpiryPolicyFactory, which allows us to set up default expiry policy. > things could get worse if we decided to add a few more WithSomething* methods I don't think this is a good argument - we should decide on case by case basis. Anyway, other With* methods don't have any parameters, so they carry only 1 bit of information. https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients On Fri, Oct 18, 2019 at 5:14 PM Alexandr Shapkin <lexw...@gmail.com> wrote: > Igniters, > > I would like to add WithExpirePolicy support to thin clients. [1] > For a thick client, we can obtain a reference to a cache wrapper instance > and use cache API through it. At the same time, the thin client protocol is > stateless, we do not hold a reference to a cache but rather a cache name > identifier is used for a server to create an appropriate cache instance. > > We could extend the protocol as we did with WithKeepBinaryMethod: > every time we need to call some API on a cache with expiration, a > serialized ExpiryPolicy (additional 3*8 bytes) would be sent. This approach > works well, but things could get worse if we decided to add a few more > WithSomething* methods. > > Initially, I was thinking about introducing some state context to a > protocol, similar to a QueryCursor API. For instance, we can save an expire > policy configuration for the first call and use some hash value based on an > ExpiryPolicy for further calls, just as we do for cache names. I.e. > newCacheId = [cacheId, new AdditionalValues(expiryPolicyId, binaryModeId, > ....)] But this approach complicates logic and leads to additional memory > consumption. > > I think it's ok for now to use the first approach with ExpiryPolicy > serialization. > But any ideas are welcome. > > [1] - https://issues.apache.org/jira/browse/IGNITE-9033 > >
