Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] service discovery working even if port mis configured

Hi Peter,

On 4/24/2014 5:02 AM, Peter Hermsdorf wrote:
Hi,

Hopefully this will get you well on the way. At some point in the future...if desired...I could probably refactor and move the EDEFBundleGenerator into ECF API rather than test code, but this can't happen right away as we are closing in on Luna freeze).
using a static edef xml file I have a working environment now.

little pitfall was to strip down the edef xml file to the bare minimum and especially replacing the numeric id for endpoint.id from the examples with ecftcp://localhost:8889/server.

Before investing into the "dynamic edef" approach: how to trigger a rediscovery of services? Stopping and starting the bundle with the edef programmatically should work but seems a bit odd...

Perhaps odd...but I think for your purposes that's the easiest way. There are other ways, of course, but they require getting a service, making method calls, etc.



When stopping the host there is an unbind event on the client, but when restarting the host there is no new bind event.

I don't think I understand what exactly you mean by 'stopping the host'. Do you mean just remote service unregistration?...or do you mean unceremonious host shutdown (e.g. kill -9 ), or something in between, or ?

For our use case it would be a requirement to trigger a reconnect if the connection gets lost.

Although this behavior is well supported by ECF RS and the generic provider, it's not exposed directly as part of the OSGi RS/RSA impl.


I've tried the zookeeper discovery in standalone mode and I see that the client is trying to reconnect to the server when the connection is lost and reconnects when the server is up again.

Yes...that's the default behavior of the zookeeper discovery provider...but that's for discovery...as opposed to distribution/remote services.


So maybe that's the way to go for us?

I'm not sure. I think it hinges on what you want WRT the 'stopping the host' and the 'restart leading to new bind event'.



Bonus Question: when starting (only) the host with zookeper and using "centralized" for the zoodiscovery.flavor, there are error messages (for the host) which seem to come from a client trying connect.

WARN [ClientCnxn] Session 0x0 for server null, unexpected error, closing socket connection and attempting reconnect

Whats the reason and/or background for that behavior?

I'm going to have to punt to Wim Jongman (ECF committer) on that. Wim is the committer primarily responsible for zookeeper discovery...and he knows much more about it's internals that I do.

Thanks,

Scott




Back to the top