Comment 1 Scott Lewis 2011-01-11 14:33:19 EST

Hi Martin,

I think that what you are seeing (no service proxy being created...with service.imported set) is because the default behavior is to ignore loopback (localhost) remote services as per bug 326866.  

In the log output you provide below is this line:

[log;+0100 2011.01.11
19:29:00:700;INFO;org.eclipse.ecf.osgi.services.discovery;org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.discovery;code=1;message=serviceDiscovered:ignoring
loopback ServiceReference:
ServiceID[type=ServiceTypeID[typeName=_osgiservices._tcp.default._iana];location=osgiservices://192.168.0.104:9279/svc_nc1fz4nXXOSLbEhG9JpFqMI6r6w=;full=_osgiservices._tcp.default._iana@osgiservices://192.168.0.104:9279/svc_nc1fz4nXXOSLbEhG9JpFqMI6r6w=];severity1;exception=null;children=[]]]

You can defeat the default behavior (and have discovered remote services result in proxy creation...with the service.imported property set), by setting this system property:

-Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=true

We know that this needs to be better/consistently documented.  Any contributions to that effect would be most welcome.

Comment 2 Martin Petzold 2011-01-12 05:36:06 EST

(In reply to comment #1)
> [...]
> -Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=true
> 
> We know that this needs to be better/consistently documented.  Any
> contributions to that effect would be most welcome.

I don't think a system property is that nice. I think there is missing something in the OSGi RS spec about loopback handling (have posted it there).

From my point of view I now would set a filter with "(!(service.remote.registration=true))" and then would have only local and remote services without loopback remote services (as I want to have). But this would be inconsistent with other RS implementations e.g. CXF-DOSGi?!

I now don't get the loopback services with this filter. BUT I now have something different, I have TWO registrations of a remote service (from another OSGi instance provided!):

----------> this is with the filter and one remote service registered (loopback filtered out) - okay!

[12.01.2011 11:17:18][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.exported.configs -> ecf.r_osgi.peer
[12.01.2011 11:17:18][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.exported.interfaces -> *
[12.01.2011 11:17:18][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: objectClass -> [Ljava.lang.String;@6d4c4d61
[12.01.2011 11:17:18][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.id -> 28

----------> this comes up if I register a remote service in another OSGi instance

[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: ecf.rsvc.cid -> r-osgi://jumper:9279
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: ecf.rsvc.ranking -> 0
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: ecf.rsvc.id -> 50
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.uri -> r-osgi://jumper:9279#50
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: ecf.robjectClass -> [Ljava.lang.String;@3be0e954
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.id -> 56
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: objectClass -> [Ljava.lang.String;@2af6a882
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] INFO : Node 25557f7c-60c9-46b6-b82d-a4485b733c7b has been registered!
[log;+0100 2011.01.12 11:17:39:310;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=devsosgi.INodeAsync for proxy service class=devsosgi.INode;severity2;exception=null;children=[]]]
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.id -> 57
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: objectClass -> [Ljava.lang.String;@2d9f90e3
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.imported -> org.eclipse.ecf.internal.provider.r_osgi.RemoteServiceImpl@46e13e7b
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] DEBUG: Property: service.imported.configs -> [Ljava.lang.String;@6dcd2197
[12.01.2011 11:17:39][devsosgi.controller.gui.panels.node.NodeTracker] INFO : Node 25557f7c-60c9-46b6-b82d-a4485b733c7b has been registered!

Comment 3 Markus Kuppe 2011-01-12 05:43:28 EST

Why do you need the remoted service in the local framework in the first place?

Comment 4 Martin Petzold 2011-01-12 05:52:39 EST

(In reply to comment #3)
> Why do you need the remoted service in the local framework in the first place?

I could cope with this filter "(|(service.imported=*)(service.remote.registration=true))". But I would like to have the local registration because the performance calling this is better? Wouldn't it use the proxy and network if I have the remote one?

The new behaviour I described above (part 2) is just with a remote service without loopback (beacuse different OSGi instance), why are there two registrations for this?

I'm sorry but all this behaviour is very confusing and not very intuitive!

Comment 5 Markus Kuppe 2011-01-12 06:05:30 EST

(In reply to comment #4)
> (In reply to comment #3)
> > Why do you need the remoted service in the local framework in the first place?
> 
> I could cope with this filter
> "(|(service.imported=*)(service.remote.registration=true))". But I would like
> to have the local registration because the performance calling this is better?
> Wouldn't it use the proxy and network if I have the remote one?
> 
> The new behaviour I described above (part 2) is just with a remote service
> without loopback (beacuse different OSGi instance), why are there two
> registrations for this?
> 
> I'm sorry but all this behaviour is very confusing and not very intuitive!

Why do you query for remoted service references (by filter), if you're no interested in remoted service references? Without a filter and -Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=false (default) you won't get the remoted reference in the provider framework in general and thus use local invocation semantics.

For r-OSGi you get two references though, due to an implementation detail (r-OSGi reregisters the to be remoted service with the service registry a second time). But still, both references use local invocation semantics (no overhead).

Comment 6 Martin Petzold 2011-01-12 06:17:49 EST

(In reply to comment #3)
> [...]
> Why do you query for remoted service references (by filter), if you're no
> interested in remoted service references? Without a filter and
> -Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=false
> (default) you won't get the remoted reference in the provider framework in
> general and thus use local invocation semantics.
> 

I am interested in remote service references, all of them. But I want ALL remote ones + the local ones (without the loopback services). So this filter is then "(!(service.remote.registration=true))". 

> For r-OSGi you get two references though, due to an implementation detail
> (r-OSGi reregisters the to be remoted service with the service registry a
> second time). But still, both references use local invocation semantics (no
> overhead).

But why does r-OSGi reregisters the to be remoted service with the service registry a second time? There is some mess of services in the registry which has to be filtered out (and this also implementation specific, so there is no standardization!). I think this again is very confusing, I now have to do another filtering of the services.

I often hear OSGi would be to complex, difficult and not intuitive. At this point it is exaactly this (I have postet it to osgi-dev).

Comment 7 Markus Kuppe 2011-01-12 06:34:28 EST

(In reply to comment #6)
> (In reply to comment #3)
> > [...]
> > Why do you query for remoted service references (by filter), if you're no
> > interested in remoted service references? Without a filter and
> > -Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=false
> > (default) you won't get the remoted reference in the provider framework in
> > general and thus use local invocation semantics.
> > 
> 
> I am interested in remote service references, all of them. But I want ALL
> remote ones + the local ones (without the loopback services). So this filter is
> then "(!(service.remote.registration=true))".

Why? What's your use case?

> > For r-OSGi you get two references though, due to an implementation detail
> > (r-OSGi reregisters the to be remoted service with the service registry a
> > second time). But still, both references use local invocation semantics (no
> > overhead).
> 
> But why does r-OSGi reregisters the to be remoted service with the service
> registry a second time? There is some mess of services in the registry which
> has to be filtered out (and this also implementation specific, so there is no
> standardization!). I think this again is very confusing, I now have to do
> another filtering of the services.

It's the way the r-OSGi wrapper has been implemented to accommodate both usage with and without OSGi remote services. We are always open to contributions that enhance the current implementation though.

> I often hear OSGi would be to complex, difficult and not intuitive. At this
> point it is exaactly this (I have postet it to osgi-dev).

Feel free to choose some other technology.

Comment 8 Martin Petzold 2011-01-12 06:55:18 EST

I really appreciate all of your help, this is great!

I will stay with OSGi in near future and would like to have it as intuitive and
well specified as possible. No offense. I just try to give feedback from my use
case and I will document everything I have learnt!

Comment 9 Markus Kuppe 2011-01-12 07:01:30 EST

(In reply to comment #8)
> I just try to give feedback from my use
> case and I will document everything I have learnt!

But what is you use case?

Retrieving both remoted as well as local service references in the provider framework is not a regular use case.

Comment 10 Martin Petzold 2011-01-12 07:09:16 EST

(In reply to comment #9)
> (In reply to comment #8)
> > I just try to give feedback from my use
> > case and I will document everything I have learnt!
> 
> But what is you use case?
> 
> Retrieving both remoted as well as local service references in the provider
> framework is not a regular use case.

I have x (let's say 1000) Simulator services in my simulation/service ecosystem. They have sub dependencies, so Simulator A could have Simulator B and C as children (and needs to call them via remote services). As my simulation system is distributed the children A and B could be in the same OSGi framework on a node or on some other OSGi framework on another node. This can also change while runtime (so it's also dynamic).

I have implemented the whole simulation framework feature complet now (non distributed execution works fine) and just have some of these problems with my sets of remote simulator services I locate. Of course there a also some more services PortHandler, Node etc. int te ecosystem too.

Comment 11 Markus Kuppe 2011-01-12 07:19:28 EST

(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > I just try to give feedback from my use
> > > case and I will document everything I have learnt!
> > 
> > But what is you use case?
> > 
> > Retrieving both remoted as well as local service references in the provider
> > framework is not a regular use case.
> 
> I have x (let's say 1000) Simulator services in my simulation/service
> ecosystem. They have sub dependencies, so Simulator A could have Simulator B
> and C as children (and needs to call them via remote services). As my
> simulation system is distributed the children A and B could be in the same OSGi
> framework on a node or on some other OSGi framework on another node. This can
> also change while runtime (so it's also dynamic).
> 
> I have implemented the whole simulation framework feature complet now (non
> distributed execution works fine) and just have some of these problems with my
> sets of remote simulator services I locate. Of course there a also some more
> services PortHandler, Node etc. int te ecosystem too.

This use case is fully supported by the current implementation and will get optimal performance if allowLoopbackReference is false. You might get a service reference in the provider framework that has service.imported=* with r-OSGi, but this service reference still provider local invocation semantics.

However, if a second framework additionally registers services with the local runtime, you will have to use custom filter code to choose the local service ref over the remote one. This can either be done in client code (e.g. ServiceTracker) or with OSGi remote service admin.

Comment 12 Martin Petzold 2011-01-12 07:58:33 EST

This filter "(!(service.remote.registration=true))(!(service.imported=*))" does work now (but it's only for ECF and r-OSGi).

Comment 13 Martin Petzold 2011-02-01 08:26:16 EST

What do you think Markus, close the bug as it is more an OSGi standards issue?

Or should the r-OSGi registration of RS should be somehow a bit more clean, not registering three services under this class instance? I think this is because of downwards compatibility?

Comment 14 Markus Kuppe 2011-02-01 10:37:16 EST

(In reply to comment #13)
> What do you think Markus, close the bug as it is more an OSGi standards issue?
> 
> Or should the r-OSGi registration of RS should be somehow a bit more clean, not
> registering three services under this class instance? I think this is because
> of downwards compatibility?

Unless you have a (enhancement) patch for r-OSGi in the pipeline that optimizes r-OSGi' behavior to be differently in the remote services context, I'd suggest we close this one as won't fix.

Comment 15 Martin Petzold 2011-02-20 18:26:14 EST

R-OSGi registeres more than one Service (Proxy) for each RS being discovered. This causes problems with the selection of multiple services of the same type via service tracker or getServiceReferences. It's a bit a mess in the service registry.

But as this is a core implementation issue of R-OSGi it won't be fixed. It's possible to a) use another distribution provider (e.g. ecf.generic) or to b) set filter properties (e.g. something like this "(!(service.imported=*))(!(service.remote.registration=true))(!(ecf.robjectClass=*))").