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 19:37:36 GMT

Alexander, I just added the change for the "update" - could you do a 
small test and verify whether this fixed the broken Amdatu/Celix 
discovery?

Regards,
   Bjoern


On 2014-10-07 21:23, Alexander Broekhuis wrote:
> 2014-10-07 20:57 GMT+02:00 Bjoern Petri <bjoern.petri@sundevil.de>:
> 
>> 
>>>> 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.
> 
> 
> Ah ok, I read the change of the interval as a possible workaround/fix, 
> not
> as addition to an "update". And yeah I agree about "update" being a 
> good
> solution. No argument there! :)
> 
>> 
>> 
>>  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.
> 
> 
> But as mentioned in my other post, this would keep the 
> "addOwnFramework"
> being called, resulting in the extra "set" calls each 10 seconds?
> 
>> 
>> 
>>  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?
>> 
> 
> I agree, something like a TTL is needed to keep the setup error-proof 
> wrt
> network issues and even software crashes. But reading the documentation 
> of
> etcd I am a bit confused.
> At [1] it mentions: "NOTE: Keys can only be expired by a cluster 
> leader, so
> if a machine gets disconnected from the cluster, its keys will not 
> expire
> until it rejoins."
> This is not something which I would expect...
> 
> 
> [1]: https://coreos.com/docs/distributed-configuration/etcd-api/

Mime
View raw message