Comment 1 Scott Lewis 2011-02-18 10:59:03 EST

Hi Martin.

In looking at the output, there is something that seems wrong (I'm not sure where the error is...it may indeed be a bug, but I'm not sure yet).

Specifically,

RemoteReferenceNotFoundException[targetID=r-osgi://jumper:9280,
idFilter=[r-osgi://jumper:9279], interfaces=[devsosgi.simulator.ISimulator,
devsosgi.simulator.IAtomicSimulator], rsFilter=(&(ecf.rsvc.id=69))]


The targetID = r-osgi://jumper:9280
and the idFilter = r-osgi://jumper:9279

typically these would be the *same*.  I don't understand how these would be different unless explicitly set to be different on service registration.

Could you detail on this bug what (if any) service properties you are setting in your service registration?  Thanks.

Comment 2 Martin Petzold 2011-02-18 12:19:14 EST

Hi Scott,

Properties properties = new Properties();
properties.put("service.exported.interfaces", "*");
properties.put("service.exported.configs", DEVSOSGiConfiguration.CONTAINER_TYPE);
properties.put("devsosgi.component.id", component.id());
properties.put("devsosgi.node.id", node_id);
ServiceRegistration simulatorRegistration = Activator.getContext().registerService(new String[]{ISimulator.class.getName(), IAtomicSimulator.class.getName()}, new AtomicSimulator(component), properties);

DEVSOSGiConfiguration.CONTAINER_TYPE = "ecf.r_osgi.peer";

I think this is because I have a more complex "topology"(?):

Controller (an OSGi framework instance)
----------------------------------------

-> tracks remote INode Service and ISimulator Services

Node A...n (OSGi framework instances)
--------------------------------------

-> registers a remote INode Service
-> registers n remote ISimulator+IAtomicSimulator Services
-> tracks own and other remote ISimulator Services

...and even more complex, these are the top level services! Also there is an ISimulatorAsync Interface. I can test all of this also only inside of one OSGi framework, this works great, it's just the distribution.

If it's the same problem as with 3.4 it is:
1. first remote ISimulator Service registered, lets say by *Node A* -> r-osgi://jumper:9279
2. On consumer side (Controller, could als be another Node) there is a (consumer) container created.
3.  second remote ISimulator Service (same service type!) registered, lets say by *Node B* -> r-osgi://jumper:9280.
-> Now the same consumer container is used, but there should be created another one, because there is a different target (*Node B*) responsible for this second service.

With 3.4 I had the container connect Exception (https://bugs.eclipse.org/bugs/show_bug.cgi?id=334787). I'm not sure, but this could be still the same problem.

I can't look at this at the moment, will work on it this weekend.

In my opinion this is no special topology use case, as e.g laod balancing or redirection, it's just 1..n services with the same service type on each side.

Comment 3 Scott Lewis 2011-02-18 12:40:17 EST

Hi Martin,

(In reply to comment #2)
> Hi Scott,
> 
> Properties properties = new Properties();
> properties.put("service.exported.interfaces", "*");
> properties.put("service.exported.configs",
> DEVSOSGiConfiguration.CONTAINER_TYPE);
> properties.put("devsosgi.component.id", component.id());
> properties.put("devsosgi.node.id", node_id);
> ServiceRegistration simulatorRegistration =
> Activator.getContext().registerService(new String[]{ISimulator.class.getName(),
> IAtomicSimulator.class.getName()}, new AtomicSimulator(component), properties);
> 
> DEVSOSGiConfiguration.CONTAINER_TYPE = "ecf.r_osgi.peer";
> 
> I think this is because I have a more complex "topology"(?):

I think it's more likely to be because of r-osgi's policies wrt running on localhost.  I expect you are trying to run mulitple processes...i.e. one on 9279 and the other on 9280...and perhaps the container selector is getting confused about which one to use for export?

> 
> Controller (an OSGi framework instance)
> ----------------------------------------
> 
> -> tracks remote INode Service and ISimulator Services
> 
> Node A...n (OSGi framework instances)
> --------------------------------------
> 
> -> registers a remote INode Service
> -> registers n remote ISimulator+IAtomicSimulator Services
> -> tracks own and other remote ISimulator Services
> 
> ...and even more complex, these are the top level services! Also there is an
> ISimulatorAsync Interface. I can test all of this also only inside of one OSGi
> framework, this works great, it's just the distribution.

Right...so it looks like some of the services are exposed by one framework, and other exposed by other frameworks...is that right?

Is more than one r-osgi container created within a single framework?  That is...is there more than one r-osgi container instance created inside one process?

> 
> If it's the same problem as with 3.4 it is:
> 1. first remote ISimulator Service registered, lets say by *Node A* ->
> r-osgi://jumper:9279
> 2. On consumer side (Controller, could als be another Node) there is a
> (consumer) container created.
> 3.  second remote ISimulator Service (same service type!) registered, lets say
> by *Node B* -> r-osgi://jumper:9280.
> -> Now the same consumer container is used, but there should be created another
> one, because there is a different target (*Node B*) responsible for this second
> service.

I see.  This is, IMHO, a weakness with r-osgi...it sort of 'wants' to have a separate container for a given consumer...but by default it opens a new server port with every new container instance...which isn't what you want on the consumer...at least for this use case.

But on the consumers...do you want the container to disconnect from the first remote service and connect to the second one?  or do you want to access both?

> 
> With 3.4 I had the container connect Exception
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=334787). I'm not sure, but this
> could be still the same problem.
> 
> I can't look at this at the moment, will work on it this weekend.

Ok.  If we need to correspond about this feel free to contact me directly at slewis at composent.com.

> 
> In my opinion this is no special topology use case, as e.g laod balancing or
> redirection, it's just 1..n services with the same service type on each side.

I think it is sort of a special topology use case, because the consumer has to to decide:  does the same service instance from two different nodes have to be imported at the same time?  Or can the first service be removed in favor of the second?

Comment 4 Scott Lewis 2013-01-29 17:09:09 EST

As per comment #3 resolving as invalid.  The associated r-osgi feature request is bug 267521.

*** This bug has been marked as a duplicate of bug 267521 ***