Re: [ecf-dev] etcd-provider - service keys to register service for disco

["Keimel, Christoph" <c.keimel@xxxxxxx>]

Hi Scott,

thanks. I will prepare a pull request. 

Since the endpoint.id is globally unique and is also generated randomly I think we could safly change the implementation to use this instead of EtcdServiceInfoKey. Or would you rather make this configurable with a system property? 

i.e. org.eclipse.ecf.provider.etcd.keyformat=endpoint.id

Cheers,
Christoph

-----Ursprüngliche Nachricht-----
Von: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Scott Lewis
Gesendet: Samstag, 26. November 2016 20:56
An: ecf-dev@xxxxxxxxxxx
Betreff: Re: [ecf-dev] etcd-provider - service keys to register service for discovery

On 11/26/2016 12:29 AM, Keimel, Christoph wrote:
> Can I use something from the framework, the endpoint-id or something like that, or would I need to invent my own service configuration property?

Yes, there is an OSGi Remote Services Admin standard property: 
endpoint.id.   If you set this property yourself (either via the service 
properties passed to the registerService call, OR in the overridingProperties passed to RemoteServiceAdmin.exportService(svcRef,overridingProperties), then the value you specify will be used for the endpoint.id in the description published by discovery (via etcd in your case).  Take care though as this endpoint.id must be globally unique...and it is usually a UUID String although having UUID syntax is not required by RSA.

Scott


>
> -----Ursprüngliche Nachricht-----
> Von: ecf-dev-bounces@xxxxxxxxxxx [mailto:ecf-dev-bounces@xxxxxxxxxxx] Im Auftrag von Scott Lewis
> Gesendet: Samstag, 26. November 2016 08:12
> An: ecf-dev@xxxxxxxxxxx
> Betreff: Re: [ecf-dev] etcd-provider - service keys to register service for discovery
>
> On 11/25/2016 12:20 PM, Keimel, Christoph wrote:
>> Hi Scott,
>>
>> I've been playing with the etcd discovery provider lately with the aim
>> of replacing zeroconf for our escape game platform. It's very nice and
>> really, really (!) fast. In the escape game deployment scenario the
>> system will be running longer than 20 minutes, which is why I set TTL
>> to 0 so the services will not be removed automatically. (The default
>> TTL is 1200 seconds.)
>>
>> This raises another issue though: As long as an application is shutdown gracefully the service key will be removed from etcd. But if you kill an application this is not the case. Unfortunately this is exactly what happens with the Raspberry Pi gateways on site. The guys power up the pi at the morning and at the evening they just kill the power to shut it down. The effect is that the keys will stay in etcd for ever. Since the keys are generated randomly for every session this leads to duplicates of services in etcd.
>>
>> I had a look at EtcdDiscoveryContainer and I was wondering if we could use a key to register the service with etcd that doesn't change between session? What do you think?
> Yeah, I imagine that you could publish/advertise a service with a
> consistent key.   I can't remember if this will require any changes to
> the etcd provider (e.g. to allow the key to be explicitly set), but if so I could probably arrange to at least help with the changes.
>
> Scott
>
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/ecf-dev
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/ecf-dev


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev