Pavel, I think that in some cases milliseconds could make sense, so I would like to keep the current precision.
With this approach we will avoid unnecessary code changes as well as keeping API in consistence with the thick client method and cacheConfiguration settings. From: Pavel Tupitsyn Sent: Saturday, October 19, 2019 9:20 PM To: dev Subject: Re: Thin clients: WithExpiryPolicy Alexandr, Sounds good to me. Remaining question is - how do we serialize the expiry policy? Thick client passes this to JNI as 3 int64 values (duration in milliseconds). But I don't think we need millisecond precision for expiration, so we could pass seconds as float values (3*4 bytes). Thoughts? On Fri, Oct 18, 2019 at 8:21 PM Alexandr Shapkin <lexw...@gmail.com> wrote: > 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 > > > > > >
