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 Fri, 18 Oct 2019 16:05:38 GMT
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*
I don't think this is a good argument - we should decide on case by case
Anyway, other With* methods don't have any parameters, so they carry only 1
bit of information.


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

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