[
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