Bugzilla – Full Text Bug Listing
| Summary: | OSGi discovery issue with generic server and jmdns | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [RT] ECF | Reporter: | Gunnar Wagenknecht <gunnar> | ||||||||
| Component: | ecf.discovery | Assignee: | Scott Lewis <slewis> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | bugs.eclipse.org, slewis | ||||||||
| Version: | 3.3.0 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows 7 | ||||||||||
| Whiteboard: | |||||||||||
| Bug Depends on: | 312363 | ||||||||||
| Bug Blocks: | |||||||||||
| Attachments: |
|
||||||||||
Hi Gunnar. I've downloaded the example projects and have them in my workspace. I need a little guidance to understand them better and be able to help more quickly. So just to verify: 1) the osgi.cloud.node starts both an ecf generic server and http server, right? (one initial question is what is the jetty http server for, but it's not a big deal...I'm just curious) 2) I noticed in the OSGi Cloud Node.product product configuration that the product configuration depends upon some bundles that I don't have available to me...yet everything compiles ok (I haven't tried to run it yet). I assume that I can just delete those from the product config and everything will start...is that right? 3) There's also a dependency on equinox configuration management (cm). Is that required or can I eliminate that too (again no compile errors, so maybe it's just not being used...but I haven't tried to launch yet). 4) It looks to me as if the Activator for OSGi Cloud Node creates an ECF generic container, and then a ds component is resolved that registers itself as a remote service...implementing NodeService class. One consequence of having the NodeService service interface in the same bundle as the host/server is that this means that when a client is created and run it will automatically start a server as well. Is that your understanding/expectation? I typically create in separate bundles: a) The service interface (NodeService) and support/serializable classes (for parameters)...along with the async service interface (if desired) b) Service Host (along with impl) c) Service Consumer So I'll stop there. If you want to have a skype session to discuss then we should arrange that...I just need to get a handle on what you are trying to do and how things are arranged...and then I expect to be able to track down the issue you are experiencing. (In reply to comment #1) > 1) the osgi.cloud.node starts both an ecf generic server and http server, > right? (one initial question is what is the jetty http server for, but it's > not a big deal...I'm just curious) Yes. The HTTP service is just for demo purposes. It allows to register a node info servlet on every node. > 2) I noticed in the OSGi Cloud Node.product product configuration that the > product configuration depends upon some bundles that I don't have available to > me...yet everything compiles ok (I haven't tried to run it yet). I assume that > I can just delete those from the product config and everything will start...is > that right? Yes. Just remove them. They are just for the demo. I forgot to remove them. > 3) There's also a dependency on equinox configuration management (cm). Is that > required or can I eliminate that too (again no compile errors, so maybe it's > just not being used...but I haven't tried to launch yet). The ConfigurationAdmin service is necessary for the NodeService. > 4) It looks to me as if the Activator for OSGi Cloud Node creates an ECF > generic container, and then a ds component is resolved that registers itself as > a remote service...implementing NodeService class. One consequence of having > the NodeService service interface in the same bundle as the host/server is that > this means that when a client is created and run it will automatically start a > server as well. Is that your understanding/expectation? Yes. Every node should be a client as well as a server. (In reply to comment #2) <stuff deleted> > > Yes. Every node should be a client as well as a server. Could you please describe the expected/desired service topology for this use case? That is, something like (e.g.): Node 1 server container on port 3333, host for NodeService (more than one?) connects to Node 2?, NodeService Proxy expected for Node 1, 2, 3? Node 2 server container on port 3334, host for NodeService(s) connects to Node 1?, NodeService Proxy expected for Node 1, 2, 3? Node 3 server container on port 3335, host for NodeService(s) connects to Node 1?, NodeService Proxy expected for Node 1, 2, 3? From our email discussion this seems right, but I'm not at all sure. One thought...if what you want to achieve is one group, where every node hosts 1 or more services...then that would indeed be easier to achieve with a single ECF container instance...where clients join the group and register their remote services using this *single* container (rather than each Node having it's own server container). Although such an approach would bear some testing with more sophisticated use cases, it should be supported by the existing implementation...and...if I'm close to understanding what you are wanting to do here...would result in better scalability and fewer resources on consumers. (For example, it would be possible, then be possible to transparently switch to JavaGroups (e.g.)-based container for using multicast messaging for distribution/remote calls). (In reply to comment #3) > (In reply to comment #2) > <stuff deleted> > > > > Yes. Every node should be a client as well as a server. > > Could you please describe the expected/desired service topology for this use > case? > Node 1 runs & exports NodeService instance for itself node sees and can use NodeService from itself, and all other nodes > Node 2 runs & exports NodeService instance for itself node sees and can use NodeService from itself, and all other nodes > Node 3 runs & exports NodeService instance for itself node sees and can use NodeService from itself, and all other nodes I only used different ports because I also want to deploy multiple nodes on one OS instance. > ...would result in better scalability and fewer resources on consumers. I know that scalability can become an issue in this setup the the number of nodes grows. However, it's really a demo scenario for no-single-point-of-failure. I've identified and fixed a problem with the naming of the services for the zeroconf-based discovery, and I believe this to be the source of at least two of the issues you identify. As well, as per bug 312363 I've repaired some issues with unregistration/clean up using the generic provider and I believe this explains the other issues not fixed by the above. I haven't yet been able to get your code going Gunnar, but I will try again to do so in subsequent days. I would appreciated it if you would try out these fixes in your environment and report results. If this doesn't solve your problems then please reopen bug with details of what's going wrong. Released fixes to HEAD. Resolving as fixed. Thanks Gunnar for reporting and testing. I have to re-open that one. It doesn't work. I even get a error message logged to the console when starting node-2. [log;+0200 2010.05.12 08:35:23:485;ERROR;org.eclipse.ecf.osgi.services.distribution;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.distribution;code=4;message=org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl:handleDiscoveredServiceAvailable:getRemoteServiceReferences result is empty. containerHelper=RemoteServiceContainer [containerID=StringID[TPtyt+foPtJYgOO6M++Fk+xZxok=], container=org.eclipse.ecf.provider.generic.TCPClientSOContainer@18a9fc8, containerAdapter=org.eclipse.ecf.provider.remoteservice.generic.RegistrySharedObject@56b93a]remoteReferences=null;severity4;exception=null;children=[]]] BTW, I have the following bundles from CVS HEAD: org.eclipse.ecf org.eclipse.ecf.discovery org.eclipse.ecf.identity org.eclipse.ecf.osgi.services.discovery org.eclipse.ecf.osgi.services.distribution org.eclipse.ecf.provider org.eclipse.ecf.provider.jmdns org.eclipse.ecf.provider.remoteservice org.eclipse.ecf.remoteservice org.eclipse.ecf.sharedobject (In reply to comment #7) > BTW, I have the following bundles from CVS HEAD: > > org.eclipse.ecf > org.eclipse.ecf.discovery > org.eclipse.ecf.identity > org.eclipse.ecf.osgi.services.discovery > org.eclipse.ecf.osgi.services.distribution > org.eclipse.ecf.provider > org.eclipse.ecf.provider.jmdns > org.eclipse.ecf.provider.remoteservice > org.eclipse.ecf.remoteservice > org.eclipse.ecf.sharedobject Ok Gunnar. I'll try your code out when I have a chance, but it will be a few days due to other commitments. If you can produce any more diagnostic output it would be helpful. FYI, you can setup IHostDiscoveryListeners and IProxyDiscoveryListeners, along with IHostDistributionListener and IProxyDistributionListener to give you output along the discovery and distribution process...and this could be helpful in diagnosing what's going wrong. See the new org.eclipse.ecf.examples.remoteservices.hello.consumer (class org.eclipse.ecf.internal.examples.remoteservices.hello.consumer.HelloConsumerApplication) and org.eclipse.ecf.examples.remoteservices.hello.host (class org.eclipse.ecf.internal.examples.remoteservices.hello.host.HelloHostApplication) for examples of setting up these listeners with the whiteboard pattern. Hi Gunnar. I'm trying to reproduce the issues you are seeing and I need some help with the expected/required launch sequence. I see that there are two product configurations: /osgi.cloud.node/OSGi Cloud Node.product and /osgi.cloud.node.client/Cloud Node.product I was assuming that the expected launch sequence was to launch the /osgi.cloud.node/OSGi Cloud Node.product and then the /osgi.cloud.node.client/Cloud Node.product When I do this, the /osgi.cloud.node/OSGi Cloud Node.product seems to startup properly...i.e. here is the output: osgi> [NODE] configuring ECF on port 11001 [NODE] starting Jetty on port 10080 [log;-0700 2010.05.12 19:34:25:515;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: VAIO [CLIENT] registering node servlet I've verified that the remote service is created (and container created) and published via zeroconf (with the ECF discovery ui) However, when I try to run /osgi.cloud.node.client/Cloud Node.product I get the following failure output (consistently): osgi> !SESSION 2010-05-12 19:39:26.546 ----------------------------------------------- eclipse.buildId=unknown java.version=1.6.0_10-rc java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US Framework arguments: -application osgi.cloud.node.client.CloudNode Command-line arguments: -application osgi.cloud.node.client.CloudNode -data C:\Documents and Settings\slewis\workspace.ecf.rt/../runtime-CloudNode.product -dev file:C:/Documents and Settings/slewis/workspace.ecf.rt/.metadata/.plugins/org.eclipse.pde.core/Cloud Node.product/dev.properties -os win32 -ws win32 -arch x86 -consoleLog -console -consoleLog !ENTRY osgi.cloud.node.client 4 0 2010-05-12 19:39:27.921 !MESSAGE !STACK 0 org.osgi.framework.BundleException: The bundle "osgi.cloud.node.client_2.0.0.qualifier [24]" could not be resolved. Reason: Missing Constraint: Require-Bundle: osgi.cloud.node; bundle-version="0.0.0" at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolverError(AbstractBundle.java:1317) at org.eclipse.osgi.framework.internal.core.AbstractBundle.getResolutionFailureException(AbstractBundle.java:1301) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:319) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1073) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337) !ENTRY org.eclipse.osgi 4 0 2010-05-12 19:39:28.000 !MESSAGE Bundle initial@reference:file:../../Documents and Settings/slewis/workspace.ecf.rt/osgi.cloud.node.client/ was not resolved. !ENTRY org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE One or more bundles are not resolved because the following root constraints are not resolved: !SUBENTRY 1 org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE Bundle initial@reference:file:../../Documents and Settings/slewis/workspace.ecf.rt/osgi.cloud.node/ was not resolved. !SUBENTRY 2 osgi.cloud.node 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing required bundle org.eclipse.equinox.http.jetty_2.0.0. !SUBENTRY 1 org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE Bundle initial@reference:file:../../Documents and Settings/slewis/workspace.ecf.rt/osgi.cloud.node.client/ was not resolved. !SUBENTRY 2 osgi.cloud.node.client 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing imported package javax.servlet_2.5.0. !SUBENTRY 2 osgi.cloud.node.client 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing imported package javax.servlet.http_2.5.0. !ENTRY org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists: !SUBENTRY 1 org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE Bundle osgi.cloud.node_1.0.0.qualifier [10] was not resolved. !SUBENTRY 2 osgi.cloud.node 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing required bundle org.eclipse.equinox.http.jetty_2.0.0. !SUBENTRY 1 org.eclipse.osgi 2 0 2010-05-12 19:39:28.031 !MESSAGE Bundle osgi.cloud.node.client_2.0.0.qualifier [24] was not resolved. !SUBENTRY 2 osgi.cloud.node.client 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing required bundle osgi.cloud.node_0.0.0. !SUBENTRY 2 osgi.cloud.node.client 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing imported package javax.servlet_2.5.0. !SUBENTRY 2 osgi.cloud.node.client 2 0 2010-05-12 19:39:28.031 !MESSAGE Missing imported package javax.servlet.http_2.5.0. !ENTRY org.eclipse.osgi 4 0 2010-05-12 19:39:28.031 !MESSAGE Application error !STACK 1 java.lang.RuntimeException: Application "osgi.cloud.node.client.CloudNode" could not be found in the registry. The applications available are: org.eclipse.equinox.app.error. at org.eclipse.equinox.internal.app.EclipseAppContainer.startDefaultApp(EclipseAppContainer.java:248) at org.eclipse.equinox.internal.app.MainApplicationLauncher.run(MainApplicationLauncher.java:29) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) Any idea what's going wrong here? Should I be starting this? Should I be starting something else beforehand? I can see that there is no application listed in the product configuration. What is the expected/required start sequence here? I've noticed that if I start *two* instances of OSGi Cloud Node I get this as output on the second one (which, except for the servlet exception seems ok): osgi> [NODE] configuring ECF on port 11001 org.eclipse.ecf.core.ContainerCreateException: createInstance at org.eclipse.ecf.provider.generic.GenericContainerInstantiator.createInstance(GenericContainerInstantiator.java:158) at org.eclipse.ecf.core.ContainerFactory.createContainer(ContainerFactory.java:288) at org.eclipse.ecf.core.ContainerFactory.createContainer(ContainerFactory.java:379) at org.eclipse.ecf.core.ContainerFactory.createContainer(ContainerFactory.java:366) at org.eclipse.ecf.core.ContainerFactory.createContainer(ContainerFactory.java:352) at osgi.cloud.node.Activator$1.addingService(Activator.java:81) at org.osgi.util.tracker.ServiceTracker$Tracked.customizerAdding(ServiceTracker.java:896) at org.osgi.util.tracker.AbstractTracked.trackAdding(AbstractTracked.java:261) at org.osgi.util.tracker.AbstractTracked.trackInitial(AbstractTracked.java:184) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:339) at org.osgi.util.tracker.ServiceTracker.open(ServiceTracker.java:273) at osgi.cloud.node.Activator.start(Activator.java:90) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:783) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:774) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:755) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:370) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:374) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1073) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:561) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:546) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:459) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:440) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337) Caused by: java.net.BindException: Address already in use: JVM_Bind at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:359) at java.net.ServerSocket.bind(ServerSocket.java:319) at java.net.ServerSocket.<init>(ServerSocket.java:185) at java.net.ServerSocket.<init>(ServerSocket.java:141) at org.eclipse.ecf.provider.comm.tcp.Server.<init>(Server.java:39)[NODE] starting Jetty on port 10080 at org.eclipse.ecf.provider.generic.TCPServerSOContainerGroup.putOnTheAir(TCPServerSOContainerGroup.java:65) at org.eclipse.ecf.provider.generic.TCPServerSOContainer.<init>(TCPServerSOContainer.java:60) at org.eclipse.ecf.provider.generic.TCPServerSOContainer.<init>(TCPServerSOContainer.java:96) at org.eclipse.ecf.provider.generic.GenericContainerInstantiator.createInstance(GenericContainerInstantiator.java:153) ... 25 more [log;-0700 2010.05.12 19:43:23:62;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [log;-0700 2010.05.12 19:43:24:171;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: VAIO [CLIENT] new node: VAIO [CLIENT] registering node servlet But I also tried starting Cloud Node product *after* staring both nodes, but got the same failure of start for Cloud Node as described above. Thanks for the help...we'll get this worked out. Created attachment 168324 [details]
Launch configurations
Can you test the attached launch configurations? They should contain all necessary options.
I started by launching the product first. Then I cloned the created launch configuration and adjusted some properties.
More specifically, the following JVM args are of interest:
-Dosgi.cloud.node.ports.start=10000
-Dosgi.cloud.node.name=NODE-1
for node 2:
-Dosgi.cloud.node.ports.start=20000
-Dosgi.cloud.node.name=NODE-2
(In reply to comment #10) > Created an attachment (id=168324) [details] > Launch configurations > > Can you test the attached launch configurations? They should contain all > necessary options. > > I started by launching the product first. Then I cloned the created launch > configuration and adjusted some properties. > > More specifically, the following JVM args are of interest: > -Dosgi.cloud.node.ports.start=10000 > -Dosgi.cloud.node.name=NODE-1 > > for node 2: > -Dosgi.cloud.node.ports.start=20000 > -Dosgi.cloud.node.name=NODE-2 Hi Gunnar. So I may have got it working, but I'm not sure :). I tried the launch configs as you sent them to me, and I found a number of necessary bundles missing from the launch config. I'm not sure if the bundles were just missing...or perhaps the PDE messed them up when then went from your workspace to mine. I'll attach the new ones to this bug. I also had to add the jmdns discovery provider, along with the ecf generic provider (and deps). I had to adjust start levels (e.g. for cm and ds and osgi.cloud.node). But after doing these things, I got this as output from the first: osgi> [NODE] configuring ECF on port 11001 [NODE] starting Jetty on port 10080 [CLIENT] registering node servlet [log;-0700 2010.05.13 22:23:28:72;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: NODE-1 And I verified with the debugger that the remove service was properly published via the ECF generic server container. Also, I verified via the ECF service discovery view that the remote service was/is published via zeroconf/jmdns. Then I started the a second copy the launch config with the system properties set as you describe, and here is this output: osgi> [NODE] configuring ECF on port 21001 [NODE] starting Jetty on port 20080 [CLIENT] registering node servlet [log;-0700 2010.05.13 22:25:02:885;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: NODE-1 [log;-0700 2010.05.13 22:25:17:838;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: NODE-2 Also, note that the NODE-1 process had this additional output when NODE-2 got started: [log;-0700 2010.05.13 22:25:05:838;INFO;org.eclipse.ecf.remoteservice;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.remoteservice;code=0;message=No async remote service interface found with name=osgi.cloud.node.service.NodeServiceAsync for proxy service class=osgi.cloud.node.service.NodeService;severity2;exception=null;children=[]]] [CLIENT] new node: NODE-2 No exceptions in output, and I can confirm that their are *two* zeroconf published services. This all seems right to me, as it seems that each node (1 and 2) is exposing a NodeService remote service, and the other is discovering both itself, and the other process' remote NodeService. Does this look right to you? Can we see if you can get to the same state? And confirm that this is what you expect to have happen? And then we can move on to debug the other parts of the problems you were seeing? Thanks. Created attachment 168503 [details]
New launch configs that begin to work
New launch configs based upon launch configs from 168324
I think given the changes in ECF remote services, and the introduction of OSGi Remote Services Admin support, this bug is no longer valid. |
Created attachment 167140 [details] example projects Note sure if this is discovery related or a remote service issue. When creating an example for a demo I stumbled upon some discovery issue. The example consist of two bundles: * osgi.cloud.node - defines and exports a NodeService (simple service for managing nodes) * osgi.cloud.node.client - a simple servlet for managing nodes remotely via the NodeService The first issue is that running nodes don't discover new nodes. - start node-1 - node-1 discovers NodeService@node-1 - start node-2 - node-2 discovers NodeService@node-2 and NodeService@node-1 - node-1 does not discover NodeService@node-2 The second issue is that when I shutdown node-2 also node-1 will loose it's service reference. - stop node-2 - node-1 discovers that NodeService@node-1 has been removed (but it hasn't) A third issue is likely related to the second. When you don't stop node-2 but node-1 then node-2 gets confused. - stop node-1 - node-2 discovers that NodeService@node-2 has been removed but it also thinks that NodeService@node-1 is still active A note on the example. You need to run it on the same machine. You need to create two distinct launch configurations and set two properties to identify a node. for node 2: -Dosgi.cloud.node.ports.start=20000 -Dosgi.cloud.node.name=NODE-2 for node 1: -Dosgi.cloud.node.ports.start=10000 -Dosgi.cloud.node.name=NODE-1