Comment 1 Martin Petzold 2011-01-19 09:26:21 EST

Error comes up on consumer (tracker) end.

Comment 2 Martin Petzold 2011-01-19 09:29:29 EST

Sorry, exception in comment #0 is provider end of course!

This exception is then on consumer (tracker) end:

Exception in thread "r-OSGi ChannelWorkerThread1" ch.ethz.iks.r_osgi.RemoteOSGiException: Unimplemented message [DELIVER_SERVICE] - XID: 27629, serviceID: 45, serviceInterfaceName: [devsosgi.INode], classInjections [devsosgi/INode.class]
	at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl.handleMessage(ChannelEndpointImpl.java:1300)
	at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl$2.run(ChannelEndpointImpl.java:288)
	at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl$1.run(ChannelEndpointImpl.java:253)
[log;+0100 2011.01.19 15:22:31:26;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:handleDiscoveredServiceAvailble:Unexpected exception with rsEndpointDescription=RemoteServiceEndpointDescriptionImpl[svcInterfaces=[devsosgi.INode];supportedConfigTypes=[ecf.r_osgi.peer];serviceIntents=null;location=null;remoteServiceId=45;discoveryServiceID=ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.default._iana];location=osgiservices://192.168.0.104:9282/svc_mHZEPkJRhuIyJvM9W+Jz3hbOdl0=;full=_osgiservices._tcp.default._iana@osgiservices://192.168.0.104:9282/svc_mHZEPkJRhuIyJvM9W+Jz3hbOdl0=];endpointID=null;endpointAsID=r-osgi://jumper:9282;connectTargetID=null;remoteServicesFilter=null;props={ecf.rsvc.ns=ecf.namespace.r_osgi.remoteservice, osgi.remote.service.interfaces=devsosgi.INode, ecf.sp.cns=ecf.namespace.r_osgi, ecf.rsvc.id=[B@4de5a0cb, org.eclipse.ecf.internal.discovery.id=[B@456c5f50, ecf.sp.ect=ecf.r_osgi.peer, ecf.sp.cid=[B@1e9f9761, nodeId=a4bd8e6c-3d8b-4823-a140-92f9ce8f257a}];severity4;exception=ch.ethz.iks.r_osgi.RemoteOSGiException: Method Invocation failed, timeout exceeded.;children=[]]]
ch.ethz.iks.r_osgi.RemoteOSGiException: Method Invocation failed, timeout exceeded.
	at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl.sendAndWait(ChannelEndpointImpl.java:1343)
	at ch.ethz.iks.r_osgi.impl.ChannelEndpointImpl.getProxyBundle(ChannelEndpointImpl.java:793)
	at ch.ethz.iks.r_osgi.impl.RemoteOSGiServiceImpl.fetchService(RemoteOSGiServiceImpl.java:867)
	at ch.ethz.iks.r_osgi.impl.RemoteOSGiServiceImpl.getRemoteService(RemoteOSGiServiceImpl.java:788)
	at org.eclipse.ecf.internal.provider.r_osgi.R_OSGiRemoteServiceContainer.getRemoteService(R_OSGiRemoteServiceContainer.java:198)
	at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.registerRemoteServiceReferences(DiscoveredServiceTrackerImpl.java:577)
	at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.handleDiscoveredServiceAvailable(DiscoveredServiceTrackerImpl.java:275)
	at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.access$4(DiscoveredServiceTrackerImpl.java:208)
	at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl$1.dispatchEvent(DiscoveredServiceTrackerImpl.java:103)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:227)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:337)

Comment 3 Markus Kuppe 2011-01-20 02:18:34 EST

Martin,

I won't have time to work on this in the next few weeks. So if you really need to get this fixed, you would have to come up with a patch yourself. If you can do this before ECF release 3.5 mid February, I'd make sure the patch ends up in it.

Comment 4 Martin Petzold 2011-01-29 07:49:09 EST

Created attachment 187905 [details]
TestCaseContainerConnectException

I have added a test case. Please start "RSConsumer.launch" and then twice(!) "RSProvider.launch".

"org.eclipse.ecf.osgi.services.distribution" and "ch.ethz.iks.r_osgi.remote" come from master. I have also synchronized the "handleMessage" in "ChannelEndpointImpl.java" of "ch.ethz.iks.r_osgi.remote". Still the exception as in #0.

Comment 5 Martin Petzold 2011-02-08 16:51:51 EST

It's not that easy to get through everything about r-osgi.

Could it be possible, that if a Service A is registered by two different OSGi frameworks another 'consumer' OSGi framework only creates one container for both?

Or perhaps the wrong container is found by 'findProxyContainers()' in 'org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl', this would then be outside of r-osgi.

Comment 6 Scott Lewis 2011-02-08 18:02:26 EST

(In reply to comment #5)
> It's not that easy to get through everything about r-osgi.
> 
> Could it be possible, that if a Service A is registered by two different OSGi
> frameworks another 'consumer' OSGi framework only creates one container for
> both?

Yes.  Without Remote Service Admin, what this would take would be to override/reimplement the IProxyContainerFinder...i.e. to customize the behavior of the container finder.  With the RSA work, the container finder classes are replaced by the IConsumerContainerSelector service...that has essentially the same function as IProxyContainerFinder.

> 
> Or perhaps the wrong container is found by 'findProxyContainers()' in
> 'org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl',
> this would then be outside of r-osgi.

I think the question would be...for your use case, what is 'wrong' and what is 'right'?  The appropriate container to use is use-case (and provider) specific...so that's why there is a customizable IProxyContainerFinder (and it's new analog in the RSA impl:  IConsumerContainerSelector.  If you need to create/use new instances of this container selector service (and/or their host-side analogs...i.e. IHostContainerFinder and IHostContainerSelector) then it's straightforward to do so...i.e. just create your new impl class (implementing IConsumerContainerSelector...and perhaps extending/overriding AbstractConsumerContainerSelector)...and registering it as a service.  Then at remote service registration time and proxy discovery/access time your implementation will be used over the default.

If you do this, I would strongly suggest that do it with the new/RSA IConsumerContainerSelector rather than the IProxyContainerFinder...as IProxyContainerFinder (and IHostContainerFinder) are going away in preference to the RSA implementation as in bug 324215.

Comment 7 Martin Petzold 2011-02-20 18:19:46 EST

This is not a bug. Problem can be addresses implementing an own Consumer/HostContainerSelector or TopologyManager.

Comment 8 Martin Petzold 2011-02-22 14:40:09 EST

If you get Exception #0 or #2 or the following. Most likely your Topology is not supported -> implement your own OSGi Remote Service Admin Topology Manager.

-----

org.eclipse.ecf.core.util.ECFException: callSync timed out after 30000ms
	at org.eclipse.ecf.internal.provider.r_osgi.RemoteServiceImpl.callSync(RemoteServiceImpl.java:125)
	at org.eclipse.ecf.internal.provider.r_osgi.RemoteServiceImpl$AsyncResult.run(RemoteServiceImpl.java:220)
Caused by: org.eclipse.equinox.concurrent.future.TimeoutException

----