Home » Archived » Eclipse Communications Framework (ECF) » r-osgi, File-based discovery
|
| Re: r-osgi, File-based discovery [message #519531 is a reply to message #519292] |
Tue, 09 March 2010 04:12   |
Eclipse User |
|
|
|
Originally posted by: news.eclipse.org.08.lemmster.de
On 03/08/2010 01:19 PM, a340859@owlpic.com wrote:
> Hello,
>
> I am trying to run a file-based discovery with the r-OSGI provider.
> I am utilizing the org.eclipse.ecf.examples.remoteservices.hello.consumer
> and org.eclipse.ecf.examples.remoteservices.hello.host
> examples.
>
> Everything is running just fine with one host and one consumer.
> However when I start an additional host (on a separate machine) the
> consumer discovers only one of them. My
> OSGI-INF/remote-service/hello-service-description-generic.xm l file is:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://localhost:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://192.168.1.242:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> </service-descriptions>
Hi,
does discovery work if you use a different interface for the second
service description? E.g. IHello2 or something like that.
Markus
|
|
| |
| Re: r-osgi, File-based discovery [message #519603 is a reply to message #519586] |
Tue, 09 March 2010 12:40 |
| Eclipse User |
|
|
|
Originally posted by: news.eclipse.org.08.lemmster.de
On 03/09/2010 12:55 PM, a340859@owlpic.com wrote:
> Eclipse User wrote on Mon, 08 March 2010 23:12
>> Hi,
>>
>> does discovery work if you use a different interface for the second
>> service description? E.g. IHello2 or something like that.
>> Markus
>
>
> No, it doesn't work. Again the same behavior - only the first entry is
> discovered.
Please file a bug and provide detailed information about your
environment/bundles/...
Markus
|
|
|
| Re: r-osgi, File-based discovery [message #519719 is a reply to message #519292] |
Tue, 09 March 2010 18:45 |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Rado,
First, with your permission (Rado), I would like to move this discussion
over to ecf-dev at eclipse.org mailing list. Is this OK with you? Here
is the page for joining that mailing list:
https://dev.eclipse.org/mailman/listinfo/ecf-dev
The reason that I would like to move this discussion over to the ECF dev
mailing list is that the handling of this use case (multiple remote
services) has a number implications...and I would like to get input from
you and others in the ECF mailing list.
So in this particular case, on the client you have created *one*
instance of the r-osgi container/client. When the first service
endpoint is discovered, that client is used to connect, get the remote
service reference for, and create the local proxy for the remote service
endpoint (in your xml file, this is likely the r-osgi://localhost:9279
endpoint).
When the *second* endpoint is 'discovered' (I put quotes around this
because you are using the local/file-based discovery, so it's just being
discovered because of the reading of the xml file), there is only *one*
r-osgi client, and since it's already connected to the first endpoint,
the no remote service container is found to handle the second remote
service endpoint, and so it can't handle it without either:
1) disconnecting from the first one...and reconnecting to the second one
2) creating a new remote service container/client to handle this second
remote service
Note that the selection between 1 and 2 is an important client-side
policy choice, because it will determine how/whether both remote
services can be used simultaneously. Further, selection of these
strategies has other effects if there are > 2 services that are
discovered (using file-based discovery and/or other discovery providers).
There are other upsides and downsides to both approaches (1 or 2). So,
for example, 2 requires more resources on the client (since there are >
1 client container instances).
So the strategy selection in these use cases (on the client side) are
sort of important...and the current OSGi 4.2 specification does not say
anything about how these situations are to be handled...at least
partially because this is kind of a policy-level choice (i.e. some
applications/clients will want to do things one way, others will want to
do things different ways).
Now, ECF has built in some flexibility into our implementation, so that
either/both approaches can be implemented fairly easily. This API is
new, and I would consider it still provisional (it's marked internal in
ECF 3.2, precisely because it likely will undergo some changes once
we/others get some more experience with it).
Specifically, we have something called the IProxyContainerFinder
service, which is responsible for *selecting* IContainer instances...on
the client...when they are discovered. There is some documentation (not
enough yet, I know), on this mechanism for extending/customizing the ECF
remote service impl in the wiki here:
http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote _Services
What happens is this:
discovery provider
--> discovers remote service
--> IProxyContainerFinder is selected (the service instance with
highest priority is selected)
--> IProxyContainerFinder.findProxyContainers is called and
returns an array of IRemoteServiceContainers. The given discovered
remote service is then registered with *all* of the
IRemoteServiceContainers returned.
The implementation of the findProxyContainers determines which container
instance is used to handle the discovered remote service.
If *no* custom/user-defined IProxyContainerFinder instances are present,
then a default one is created...and this is an instance of class
DefaultProxyContainerFinder. (Note that the DefaultProxyContainerFinder
is API also, so it can be easily subclassed to create your own
IProxyContainerFinder instance).
Now...the DefaultProxyContainerFinder already has the ability to do
strategy 2 as described above (i.e. create a new container instance of
compatible type), when a second/nth remote service is discovered. As
described briefly on the wiki page, the DefaultProxyContainerFinder has
a flag (which can be set in the constructor) that indicates whether an
appropriate IContainer instance should be created dynamically (i.e.
strategy 2). This flag is set to *false* by default...for security
reasons (if it was on by default, clients would be subject to possibly
severe denial of service attacks). There's some discussion of this
design choice on this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979
So I *believe* that if you were to use the the System property for
DefaultProxyContainerFinder (see the wiki page), your use case described
below would/could work, because with auto create container flag set to
'true' a new/second container instance would be created when your second
remote service was discovered.
If you want to do 1 (or variations thereof), it would be necessary to
create your own IProxyContainerFinder (e.g. by extending
DefaultProxyContainerFinder class and registering the service as shown
on the wiki), and in your impl of findProxyContainers you would/could
explicitly disconnect the client container (i.e.
IContainer.disconnect()), before returning from findProxyContainers.
This IProxyContainerFinder (and IHostContainerFinder for that matter)
are ECF-specific mechanisms...which aren't specified at all by the OSGi
4.2 spec...but I put them in place to support more complex use cases
(i.e. with many remote services). If we need to adjust them/add to them
or simplify them then we are open to doing this, as like I said above
they are provisional at this point, and I am interested in making them
as easy to use for as many use cases as possible (for example, perhaps
we could consider implementing strategy 1 in DefaultProxyContainerFinder
as well as 2).
One more thing. There was a bug filed recently describing a race
condition in the ECF 3.2 implementation with multiple remote services
discovered via file-based discovery (as yours is doing). That bug is here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=304427
This race condition has since been fixed/addressed, but note that the
fix is *not* in ECF 3.2 released version, as we only learned about it
since the 3.2 release. Currently our plan is to next have an ECF 3.3
release for Helios in June, but if we get enough support and desire we
could consider a 3.2.1 release before June to make this fix available.
Also, the fix is in the CVS repo (HEAD), so you can get the appropriate
bundle and try it out if you wish.
Does this make sense? Rado please let me know if it will be ok to move
this discussion to ecf-dev at eclipse.org mailing list and we will
continue this discussion further.
Thanks,
Scott
a340859@owlpic.com wrote:
> Hello,
>
> I am trying to run a file-based discovery with the r-OSGI provider.
> I am utilizing the org.eclipse.ecf.examples.remoteservices.hello.consumer
> and org.eclipse.ecf.examples.remoteservices.hello.host
> examples.
>
> Everything is running just fine with one host and one consumer.
> However when I start an additional host (on a separate machine) the
> consumer discovers only one of them. My
> OSGI-INF/remote-service/hello-service-description-generic.xm l file is:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://localhost:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://192.168.1.242:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> </service-descriptions>
>
> In fact, only the first <service-description> entry is discovered.
> Is this the right way to have more than one provider for a given service?
>
> Thanks in advance.
>
> Regards,
> Rado
>
|
|
| |
| Re: r-osgi, File-based discovery [message #625144 is a reply to message #519292] |
Tue, 09 March 2010 09:06 |
| Eclipse User |
|
|
|
Originally posted by: news.eclipse.org.08.lemmster.de
On 03/08/2010 01:19 PM, a340859@owlpic.com wrote:
> Hello,
>
> I am trying to run a file-based discovery with the r-OSGI provider.
> I am utilizing the org.eclipse.ecf.examples.remoteservices.hello.consumer
> and org.eclipse.ecf.examples.remoteservices.hello.host
> examples.
>
> Everything is running just fine with one host and one consumer.
> However when I start an additional host (on a separate machine) the
> consumer discovers only one of them. My
> OSGI-INF/remote-service/hello-service-description-generic.xm l file is:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://localhost:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://192.168.1.242:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> </service-descriptions>
Hi,
does discovery work if you use a different interface for the second
service description? E.g. IHello2 or something like that.
Markus
|
|
| |
| Re: r-osgi, File-based discovery [message #625148 is a reply to message #625145] |
Tue, 09 March 2010 12:40 |
| Eclipse User |
|
|
|
Originally posted by: news.eclipse.org.08.lemmster.de
On 03/09/2010 12:55 PM, a340859@owlpic.com wrote:
> Eclipse User wrote on Mon, 08 March 2010 23:12
>> Hi,
>>
>> does discovery work if you use a different interface for the second
>> service description? E.g. IHello2 or something like that.
>> Markus
>
>
> No, it doesn't work. Again the same behavior - only the first entry is
> discovered.
Please file a bug and provide detailed information about your
environment/bundles/...
Markus
|
|
|
| Re: r-osgi, File-based discovery [message #625149 is a reply to message #519292] |
Tue, 09 March 2010 18:45 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Rado,
First, with your permission (Rado), I would like to move this discussion
over to ecf-dev at eclipse.org mailing list. Is this OK with you? Here
is the page for joining that mailing list:
https://dev.eclipse.org/mailman/listinfo/ecf-dev
The reason that I would like to move this discussion over to the ECF dev
mailing list is that the handling of this use case (multiple remote
services) has a number implications...and I would like to get input from
you and others in the ECF mailing list.
So in this particular case, on the client you have created *one*
instance of the r-osgi container/client. When the first service
endpoint is discovered, that client is used to connect, get the remote
service reference for, and create the local proxy for the remote service
endpoint (in your xml file, this is likely the r-osgi://localhost:9279
endpoint).
When the *second* endpoint is 'discovered' (I put quotes around this
because you are using the local/file-based discovery, so it's just being
discovered because of the reading of the xml file), there is only *one*
r-osgi client, and since it's already connected to the first endpoint,
the no remote service container is found to handle the second remote
service endpoint, and so it can't handle it without either:
1) disconnecting from the first one...and reconnecting to the second one
2) creating a new remote service container/client to handle this second
remote service
Note that the selection between 1 and 2 is an important client-side
policy choice, because it will determine how/whether both remote
services can be used simultaneously. Further, selection of these
strategies has other effects if there are > 2 services that are
discovered (using file-based discovery and/or other discovery providers).
There are other upsides and downsides to both approaches (1 or 2). So,
for example, 2 requires more resources on the client (since there are >
1 client container instances).
So the strategy selection in these use cases (on the client side) are
sort of important...and the current OSGi 4.2 specification does not say
anything about how these situations are to be handled...at least
partially because this is kind of a policy-level choice (i.e. some
applications/clients will want to do things one way, others will want to
do things different ways).
Now, ECF has built in some flexibility into our implementation, so that
either/both approaches can be implemented fairly easily. This API is
new, and I would consider it still provisional (it's marked internal in
ECF 3.2, precisely because it likely will undergo some changes once
we/others get some more experience with it).
Specifically, we have something called the IProxyContainerFinder
service, which is responsible for *selecting* IContainer instances...on
the client...when they are discovered. There is some documentation (not
enough yet, I know), on this mechanism for extending/customizing the ECF
remote service impl in the wiki here:
http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote _Services
What happens is this:
discovery provider
--> discovers remote service
--> IProxyContainerFinder is selected (the service instance with
highest priority is selected)
--> IProxyContainerFinder.findProxyContainers is called and
returns an array of IRemoteServiceContainers. The given discovered
remote service is then registered with *all* of the
IRemoteServiceContainers returned.
The implementation of the findProxyContainers determines which container
instance is used to handle the discovered remote service.
If *no* custom/user-defined IProxyContainerFinder instances are present,
then a default one is created...and this is an instance of class
DefaultProxyContainerFinder. (Note that the DefaultProxyContainerFinder
is API also, so it can be easily subclassed to create your own
IProxyContainerFinder instance).
Now...the DefaultProxyContainerFinder already has the ability to do
strategy 2 as described above (i.e. create a new container instance of
compatible type), when a second/nth remote service is discovered. As
described briefly on the wiki page, the DefaultProxyContainerFinder has
a flag (which can be set in the constructor) that indicates whether an
appropriate IContainer instance should be created dynamically (i.e.
strategy 2). This flag is set to *false* by default...for security
reasons (if it was on by default, clients would be subject to possibly
severe denial of service attacks). There's some discussion of this
design choice on this bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979
So I *believe* that if you were to use the the System property for
DefaultProxyContainerFinder (see the wiki page), your use case described
below would/could work, because with auto create container flag set to
'true' a new/second container instance would be created when your second
remote service was discovered.
If you want to do 1 (or variations thereof), it would be necessary to
create your own IProxyContainerFinder (e.g. by extending
DefaultProxyContainerFinder class and registering the service as shown
on the wiki), and in your impl of findProxyContainers you would/could
explicitly disconnect the client container (i.e.
IContainer.disconnect()), before returning from findProxyContainers.
This IProxyContainerFinder (and IHostContainerFinder for that matter)
are ECF-specific mechanisms...which aren't specified at all by the OSGi
4.2 spec...but I put them in place to support more complex use cases
(i.e. with many remote services). If we need to adjust them/add to them
or simplify them then we are open to doing this, as like I said above
they are provisional at this point, and I am interested in making them
as easy to use for as many use cases as possible (for example, perhaps
we could consider implementing strategy 1 in DefaultProxyContainerFinder
as well as 2).
One more thing. There was a bug filed recently describing a race
condition in the ECF 3.2 implementation with multiple remote services
discovered via file-based discovery (as yours is doing). That bug is here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=304427
This race condition has since been fixed/addressed, but note that the
fix is *not* in ECF 3.2 released version, as we only learned about it
since the 3.2 release. Currently our plan is to next have an ECF 3.3
release for Helios in June, but if we get enough support and desire we
could consider a 3.2.1 release before June to make this fix available.
Also, the fix is in the CVS repo (HEAD), so you can get the appropriate
bundle and try it out if you wish.
Does this make sense? Rado please let me know if it will be ok to move
this discussion to ecf-dev at eclipse.org mailing list and we will
continue this discussion further.
Thanks,
Scott
a340859@owlpic.com wrote:
> Hello,
>
> I am trying to run a file-based discovery with the r-OSGI provider.
> I am utilizing the org.eclipse.ecf.examples.remoteservices.hello.consumer
> and org.eclipse.ecf.examples.remoteservices.hello.host
> examples.
>
> Everything is running just fine with one host and one consumer.
> However when I start an additional host (on a separate machine) the
> consumer discovers only one of them. My
> OSGI-INF/remote-service/hello-service-description-generic.xm l file is:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <service-descriptions xmlns="http://www.osgi.org/xmlns/sd/v1.0.0">
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://localhost:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> <service-description>
> <provide
> interface="org.eclipse.ecf.examples.remoteservices.hello.IHello "/>
> <property name="ecf.sp.cid">r-osgi://192.168.1.242:9279</property>
> <property name="ecf.sp.cns">ecf.namespace.r_osgi</property>
> <property name="ecf.sp.ect">ecf.r_osgi.peer</property>
> </service-description>
> </service-descriptions>
>
> In fact, only the first <service-description> entry is discovered.
> Is this the right way to have more than one provider for a given service?
>
> Thanks in advance.
>
> Regards,
> Rado
>
|
|
| |
| |
  |
Goto Forum:
Current Time: Fri Apr 19 14:36:21 GMT 2024
Powered by FUDForum. Page generated in 0.05469 seconds |
] 
Search
Help
Register
Login
Home
