Bug 348873

Comment 1 Alex Blewitt 2011-06-09 08:14:50 EDT

It seems here's the probem:

		Collection rsContainers = findExistingHostContainers(serviceReference,
				serviceExportedInterfaces, serviceExportedConfigs,
				serviceIntents);

		if (rsContainers.size() == 0 && autoCreateContainer) {
			// If no existing containers are found we'll go through
			// finding/creating/configuring/connecting
			rsContainers = createAndConfigureHostContainers(serviceReference,

It can't be finding the container after the declarative service is disabled and then re-enabled, and thus going for the createAndConfigure to create a new one.

(I'm also happy if this is an issue with the org.eclipse.ecf.osgi.services.distribution but I think the problem is the R-OGSi container seems to be crashing.)

Comment 2 Scott Lewis 2011-06-09 11:44:53 EDT

(In reply to comment #1)
> It seems here's the probem:
> 
>         Collection rsContainers = findExistingHostContainers(serviceReference,
>                 serviceExportedInterfaces, serviceExportedConfigs,
>                 serviceIntents);
> 
>         if (rsContainers.size() == 0 && autoCreateContainer) {
>             // If no existing containers are found we'll go through
>             // finding/creating/configuring/connecting
>             rsContainers = createAndConfigureHostContainers(serviceReference,
> 
> It can't be finding the container after the declarative service is disabled and
> then re-enabled, 

I don't (yet) understand why it's not finding the r-osgi container when the ds component is reactivated...as unless you explicitly remove the r-osgi container when your ds component deactivates, it should still be present and available.  

>and thus going for the createAndConfigure to create a new one.

I agree with your analysis...but I don't understand why it's not finding the existing r-osgi container.

In your remote service registration...are you specifying the standard OSGI remote services property 'service.exported.configs'? e.g. (in ds markup)

   <property name="service.exported.configs" type="String" value="ecf.r_osgi.peer"/>

The reason this is important is that when there are two or more providers present (e.g. r-osgi and generic)...and no service.exported.configs is specified...one has to be picked as the default...and it seems from your stack trace that perhaps the generic one is being picked.  The OSGi remote service spec defines 'service.exported.configs' as the way to specify a specific provider.

Note also that if you don't want the generic provider as the default for ECF RSA to use, then you can reset the default with this system property:

org.eclipse.ecf.osgi.services.remoteserviceadmin.hostDefaultConfigType

e.g.

-Dorg.eclipse.ecf.osgi.services.remoteserviceadmin.hostDefaultConfigType=ecf.r_osgi.peer

>(I'm also happy if this is an issue with the
>org.eclipse.ecf.osgi.services.distribution but I think the problem is the
>R-OGSi container seems to be crashing.)

You may be right...but I can't tell yet if it's just an issue of which provider is being used to export/reexport, or whether something is going wrong with r-osgi on your component deactivation.

Comment 3 Alex Blewitt 2011-06-09 12:15:52 EDT

I'm not specifying the services.exported.configs property; I'm just hoping it will find it by virtue of the r-osgi container being present (and started). I'm also not sure why the generic container is there - I'm guessing that it's because I had the org.eclipse.ecf.provider bundle in my runtime, which seems to be needed via the provider.r_osgi and provider.remoteservice bundles. (So, as a corollary, there's no way of using r_osgi without the generic ECF server being installed - yet another reason why the generic ECF server needs to auto-choose a port!)

It's fairly easy for me to reproduce - is there an OSGi service I can look for that disappears which will confirm one way or another?

Comment 4 Alex Blewitt 2011-06-09 12:24:07 EDT

FWIW I only have one component. It may also be a race condition with my remote container. When the service gets removed, it's possible that it's being returned by the remote container (as the service may not have gone away at that point).

Comment 5 Alex Blewitt 2011-06-09 12:35:06 EDT

So, putting the service.exported.configs switched it over to using R-OSGi. So I was obviously using the generic container before unknowingly.

The question is then why the generic container goes away comes to mind :) Also, if the port is selected at startup and then it attempts to re-use that port, the serversocket may not have been closed (and so tries to re-use the same one, giving that error message). 

I get an error when I disable and re-enable the component again. Let me see if I can replicate the example on one of the out-of-the-box ECF samples to rule out problems with my discovery container.

Comment 6 Scott Lewis 2011-06-09 12:47:07 EDT

(In reply to comment #3)
> I'm not specifying the services.exported.configs property; I'm just hoping it
> will find it by virtue of the r-osgi container being present (and started). I'm
> also not sure why the generic container is there - I'm guessing that it's
> because I had the org.eclipse.ecf.provider bundle in my runtime, which seems to
> be needed via the provider.r_osgi and provider.remoteservice bundles. (So, as a
> corollary, there's no way of using r_osgi without the generic ECF server being
> installed 

You can use service.exported.configs or set the default provider as per comment 2.

(In reply to comment #5)
> So, putting the service.exported.configs switched it over to using R-OSGi. So I
> was obviously using the generic container before unknowingly.
> 
> The question is then why the generic container goes away comes to mind :) 

I don't understand what you mean by this.

> Also,
> if the port is selected at startup and then it attempts to re-use that port,
> the serversocket may not have been closed (and so tries to re-use the same one,
> giving that error message). 
> 
> I get an error when I disable and re-enable the component again. 

What error are you receiving now that you are explicitly specifying the use of the r-osgi container?  Is it the same as reported in the original bug report? (i.e. port in use?)

Let me see if
> I can replicate the example on one of the out-of-the-box ECF samples to rule
> out problems with my discovery container.

Ok.

Comment 7 Markus Kuppe 2011-06-09 12:58:36 EDT

(In reply to comment #3)
> I'm not specifying the services.exported.configs property; I'm just hoping it
> will find it by virtue of the r-osgi container being present (and started).

This goes into the direction of bug #326132

Comment 8 Alex Blewitt 2011-06-09 13:04:46 EDT

I like the idea of bug #326132 which looks up an OSGi service based on priority and picks the highest one :)

I've tried to reproduce this problem with the Hello DS example, switching the ecf.generic.server for ecf.r_osgi.peer, but that seems to work as expected. So something else is odd with my set up.

At least now I know it's registering it via r_osgi, thanks to me setting it in the service.exported.configs.

Let me see if I can create a pared down example to attach to this bug, or dig deeper into the problem.

Comment 9 Alex Blewitt 2011-06-09 13:18:09 EDT

Hmm... wondering if it's my container at fault (again). It's a different error:

osgi> [log;+0100 2011.06.09 18:15:21:172;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:registerRemoteServiceReferences:Remote service is null for remote reference RemoteServiceReference[remoteServiceID=org.eclipse.ecf.remoteservice.RemoteServiceID[containerID=r-osgi://myhostname:9280;containerRelativeID=63];ref=RemoteServiceReference{r-osgi://myhostname:9280#63-[com.gs.example.foo.IFoo]}];severity4;exception=null;children=[]]]

I think I'm ending up with two services for my published service, so when I unregister it tries to bind to the phantom twin. But by the time the phantom twin goes, tie 'getService' will return null. And so my container still thinks there's a service there, when in fact the service reference will never resolve. In turn, that throws an exception whcih prevents any other listeners down the line seeing it.

Comment 10 Scott Lewis 2011-06-09 13:28:29 EDT

(In reply to comment #7)
> (In reply to comment #3)
> > I'm not specifying the services.exported.configs property; I'm just hoping it
> > will find it by virtue of the r-osgi container being present (and started).
> 
> This goes into the direction of bug #326132

I have no objection to such a strategy...in fact, the IHostContainerSelector structure allows such strategies to be pretty easily implemented and substituted for the default behavior.

Comment 11 Alex Blewitt 2011-06-09 14:21:19 EDT

I think this can be resolved INVALID - I was returning the set of advertised services as well as discovered, and I had another bug which was tickling a different kind of problem. With those two fixed, this seems to work now.

Comment 12 Markus Kuppe 2011-06-09 14:22:47 EDT

Closing as per comment