Return-Path: X-Original-To: apmail-ignite-dev-archive@minotaur.apache.org Delivered-To: apmail-ignite-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8009510181 for ; Mon, 16 Feb 2015 15:08:56 +0000 (UTC) Received: (qmail 80387 invoked by uid 500); 16 Feb 2015 15:08:33 -0000 Delivered-To: apmail-ignite-dev-archive@ignite.apache.org Received: (qmail 80352 invoked by uid 500); 16 Feb 2015 15:08:33 -0000 Mailing-List: contact dev-help@ignite.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.incubator.apache.org Delivered-To: mailing list dev@ignite.incubator.apache.org Received: (qmail 80339 invoked by uid 99); 16 Feb 2015 15:08:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2015 15:08:33 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of vozerov@gridgain.com designates 209.85.216.170 as permitted sender) Received: from [209.85.216.170] (HELO mail-qc0-f170.google.com) (209.85.216.170) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Feb 2015 15:08:07 +0000 Received: by mail-qc0-f170.google.com with SMTP id c9so12817325qcz.1 for ; Mon, 16 Feb 2015 07:08:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=l7cyl5pvusTO19yIiN6fv43qDkI7NX0iC/aIyhdo7BU=; b=cQ5UHTVWjwXIEwljsda0Rqgj6dTxsMQTk3GzNyovcDjxj/pp4EOjFMrlppGlZ23U8r IQch/hXg+AEuXa0UxTL69G6F89AegsCMuXKFDY7o8VM7lGpLPpnrISi8wyshBEHyh2ki VF5Vl3KjA9IYfHxQpgmR+28kVFP6HOiJKGyXPLpejs985uRAgRY1Ezyb066QOQhYlvEi ThAkPwe66NQ+2zIetzyZG+1UQepWo4wqrvxr5rkJSupG4RGyf4Aqke1sB7nwk3EzbEUi CnqDeZ4eI4uf4ceNNXljmLYRtTNioPvDQLD7xpkmZ8YyTjcHh42Z7618Bn0JP5Zc8zJI RTZg== X-Gm-Message-State: ALoCoQkCkwusgIltaRAntO5q1hkZR3NS0KnZWyj/RFP/jz6orf9Oh14MhMxGmdlAx0MOkvKOLLUE MIME-Version: 1.0 X-Received: by 10.140.231.73 with SMTP id b70mr714846qhc.76.1424099286273; Mon, 16 Feb 2015 07:08:06 -0800 (PST) Received: by 10.140.32.35 with HTTP; Mon, 16 Feb 2015 07:08:06 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Feb 2015 18:08:06 +0300 Message-ID: Subject: Re: TTL and expire time for data center replication. From: Vladimir Ozerov To: dev@ignite.incubator.apache.org Content-Type: multipart/alternative; boundary=001a1136f09e155d0e050f35f423 X-Virus-Checked: Checked by ClamAV on apache.org --001a1136f09e155d0e050f35f423 Content-Type: text/plain; charset=UTF-8 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 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 > 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 >> 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 >> > 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. >> > > >> > >> > > --001a1136f09e155d0e050f35f423--