Return-Path: X-Original-To: apmail-celix-dev-archive@www.apache.org Delivered-To: apmail-celix-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D84CF178A2 for ; Tue, 7 Oct 2014 18:42:52 +0000 (UTC) Received: (qmail 20513 invoked by uid 500); 7 Oct 2014 18:42:52 -0000 Delivered-To: apmail-celix-dev-archive@celix.apache.org Received: (qmail 20480 invoked by uid 500); 7 Oct 2014 18:42:52 -0000 Mailing-List: contact dev-help@celix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@celix.apache.org Delivered-To: mailing list dev@celix.apache.org Received: (qmail 20468 invoked by uid 99); 7 Oct 2014 18:42:52 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2014 18:42:52 +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 (athena.apache.org: domain of a.broekhuis@gmail.com designates 209.85.192.50 as permitted sender) Received: from [209.85.192.50] (HELO mail-qg0-f50.google.com) (209.85.192.50) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Oct 2014 18:42:47 +0000 Received: by mail-qg0-f50.google.com with SMTP id q108so5824274qgd.37 for ; Tue, 07 Oct 2014 11:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=qp/VOI5IWwZ+K1DyoW3VN87ToALdBZIWxDjXPfKb9r4=; b=PJ/D0xsfQMoBRF9YwYgxFqxGzLCwKn/f/w8R80clMZdlJwnh5QFc7xn84qzRXaa9Uf LokYRCBt5v6/hr9++610RqjR/wZEl8LCW58ru8F2BVjrDBIZtklBtPZ1KwMAXPsjjQp+ VOTcYzf7RoD6C9rc4eNlcmMT9isw2tZG/khOPQxb47c8HONusnvghZOLnkDoJS02u6Hf BN+SIVubtWXhRPZcDOfyDNv1mkf6Dh3Onb9k73MSNb1sSXhXLfEh6izOptX1I8nxaESW B7C9FwtyvzoXbcR1bggIwlSx7ahuxpI5bqtm49smDMoJccpMDkgZiIz62nrxDg5q3rDc cuxQ== MIME-Version: 1.0 X-Received: by 10.140.39.37 with SMTP id u34mr38353811qgu.36.1412707346910; Tue, 07 Oct 2014 11:42:26 -0700 (PDT) Received: by 10.96.233.73 with HTTP; Tue, 7 Oct 2014 11:42:26 -0700 (PDT) In-Reply-To: <141e6a9c9585ba780f7cd25da0d75162@mail.sundevil.de> References: <20140925045629.522A32388993@eris.apache.org> <141e6a9c9585ba780f7cd25da0d75162@mail.sundevil.de> Date: Tue, 7 Oct 2014 20:42:26 +0200 Message-ID: Subject: Re: svn commit: r1627454 - in /celix/trunk/remote_services/discovery_etcd/private: include/etcd.h src/etcd.c src/etcd_watcher.c From: Alexander Broekhuis To: dev@celix.apache.org Content-Type: multipart/alternative; boundary=001a11c120d29596570504d98f06 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c120d29596570504d98f06 Content-Type: text/plain; charset=UTF-8 2014-10-07 20:38 GMT+02:00 Bjoern Petri : > > The Amdatu implementation does not yet support TTL. But is this behaviour >> as expected? I don't think a TTL update should trigger a "set" on the >> other >> ends.. >> >> What do you think? >> > > Indeed, an "update" would be the nicer solution - this is unfortunately > not yet supported by the Celix implementation - I will add it within the > next days. > > We could also change the update interval from 10 seconds, if you'd like > to. I just choose a value not that high, so I don't need to wait that long > when shutting down the discovery_etcd. > I don't think the solution is in changing a value, because then after that time, the other ends would still toggle all services because of the "set", which should not happen. Looking at the code, a TTL of 0 means no TTL. Is this correct? In that case I can set the TTL to 0. If this is not the case, this update breaks interop with Amdatu, which I think we don't want. Disabling the TTL would be a reasonable fix I guess. -- Met vriendelijke groet, Alexander Broekhuis --001a11c120d29596570504d98f06--