ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Thin clients: WithExpiryPolicy
Date Sat, 19 Oct 2019 18:20:00 GMT
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 <lexwert@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 <lexwert@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
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message