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.pe...@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/
