ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: TTL and expire time for data center replication.
Date Mon, 16 Feb 2015 15:08:06 GMT
I'm wrong. Not TTL, but expire time. We do have to pass TTL over wire to
handle time difference on nodes, but why do we have to pass expire time?
Ideally we have to calculate expire time only once: when entry is submitted
to GridCacheTtlManager. Will it work?

On Mon, Feb 16, 2015 at 6:01 PM, Vladimir Ozerov <vozerov@gridgain.com>
wrote:

> Ok, what about removing TTL from cache completely? Given that we removed
> ttl()/expireTime() methods from public API, it appears that this concept is
> not needed anymore. We only need to know expire time to remove the entry
> from cache.
>
> On Mon, Feb 16, 2015 at 5:54 PM, Semyon Boikov <sboikov@gridgain.com>
> wrote:
>
>> We have special 'expiry policy projection' (IgniteCache.withExpiryPolicy)
>> and expiration can be set per-entry, so I think it isn't possible to
>> implement DR change you suggest.
>>
>> On Mon, Feb 16, 2015 at 5:39 PM, Vladimir Ozerov <vozerov@gridgain.com>
>> wrote:
>>
>> > One more question - do we still need TTL in cache? I have a feeling
>> that it
>> > is possible to remove it from cache completely, isn't it?
>> >
>> > On Mon, Feb 16, 2015 at 5:30 PM, Vladimir Ozerov <vozerov@gridgain.com>
>> > wrote:
>> >
>> > > Hi,
>> > >
>> > > Currently our data center replication code in Ignite depends on the
>> fact
>> > > that DR engine will pass explicit TTL and expire time for each cache
>> > entry.
>> > > This is so because earlier in GridGain it was possible to set separate
>> > TTL
>> > > for each cache entry.
>> > >
>> > > With the latest changes we have one ExpiryPolicy per cache. Therefore,
>> > all
>> > > entries will have the same expiration logic. I think we can remove
>> > explicit
>> > > TTL and expire time from DR logic with the following assumptions:
>> > > 1) By default receiver cache will apply it's own expiration policy for
>> > > entries from remote cache assuming that caches in both data centers
>> have
>> > > the same expiration logic.
>> > > 2) If it is necessary to define different expiration policy for remote
>> > > cache, it could be overriden in cache plugin (separate method will be
>> > added
>> > > to DR manager).
>> > >
>> > > This will remove lot's of spaghetty-like code from Ignite and will
>> reduce
>> > > DR entry size by 16 bytes.
>> > >
>> > > Any objections in this?
>> > >
>> > > Vladimir.
>> > >
>> >
>>
>
>

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