celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bjoern Petri <bjoern.pe...@sundevil.de>
Subject Re: svn commit: r1627454 - in /celix/trunk/remote_services/discovery_etcd/private: include/etcd.h src/etcd.c src/etcd_watcher.c
Date Tue, 07 Oct 2014 18:57:07 GMT
On 2014-10-07 20:42, Alexander Broekhuis wrote:
> 2014-10-07 20:38 GMT+02:00 Bjoern Petri <bjoern.petri@sundevil.de>:
>>  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.

I think you maybe misunderstood me?! I would propose to implement an 
"update" (instead of set) and in addition to align the Celix update 
interval to the Amdatu one.

> Looking at the code, a TTL of 0 means no TTL. Is this correct? In that 
> case
> I can set the TTL to 0.

Jep, setting the ttl-argument to 0 will disable the ttl.

> 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.

Well, in long-term I think also the Amdatu implementation should change 
to support ttl, don't you think so?


View raw message