celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Broekhuis <a.broekh...@gmail.com>
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:23:53 GMT
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/

-- 
Met vriendelijke groet,

Alexander Broekhuis

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