Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Mapping ServiceReferences to FrameworkUUIDs (probable race condition in RSA?)

Hi Scott,

On Wed, Apr 6, 2011 at 6:36 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
It might help if you describe a little more about what your use case is.  The reason I say this is that the RSA approach is to allow flexibility in exporting and importing of remote services (and therefore 'knowing' where they are, etc) by allowing new topology managers to be created...and the exporting and importing be explicitly controlled (by calling RemoteServiceAdmin service's exportService(ServiceReference,Map) and importService(EndpointDescription).

The whole Software was designed pre ECF 3.5 and I want to port it to the RSA. In my master thesis I created a concept for distributed OSGi services to be operated in a fault tolerant manner. To do that, I start instances of a service on multiple frameworks.
There's one component that manages them, i.e. forwarding service calls to a specific instance. Therefor, it has to differentiate the multiple instances somehow. All the component "sees" however, is a ServiceReference to an imported service. It has no idea what framework originally exported it. That's why I crated another component to map a ServiceReference to a unique framework id. That component used the IProxyDistributionListener and IHostDiscoveryListener.
 
 ECF currently has a single topology manager:  BasicTopologyManager, which implements the service EventHook (to export) and the EndpointListener (to discover and import remote services).  But the BasicTopologyManager is not at all intended to be the only topology manager...others are free to create other topology managers as needed (based upon ECF topology managers if they wish, but this is not at all required).

I already implemented my own topology manager to get familiar around with the concept.
 
What information are you looking for about the endpoint?  I guess I'm not clear on what you want to get from the remote endpoint (via the EndpointDescription).  And what do you wish to do with it...e.g. you could use it to determine whether a remote service is imported (i.e. with your own TopologyManager, you could filter on and/or look at the relevant property in the EndpointDescription and then use that to decide whether to call RemoteServiceAdmin.importService...or to do something else.

A way to find out what framework originally exported the service is exactly what I am looking for. Like you mentioned further down EndpointDescription.getId() or EndpointDescription.getFrameworkID() provide enough information to do that.
 

 Right...prior to the service being imported, the only information available (via the discovery part of RSA) is the EndpointDescription.

Just to make sure... if a service from one endpoint gets imported multiple times, each time from a different topology manager, then the RSA will only have one service registration (per EndPoint), right?
 
Only if the topology manager actually imports them.  It's possible that this is a bug, however...if they are actually imported, and rsa.getImportedEndpoints() still doesn't return them.  If you think this is what you are seeing (i.e. the service does get imported by RSA, but then subsequently does not return anything from rsa.getImportedEndpoints()...then please open a bug report and it will be examined.

I tested it once with the BasicTopologyManager and once with my own implementation (which is very close to the BasicTopologyManager anyway). The services does get imported by both TopologyManagers. After that, the EventHook is notified of the newly registered service. Even though the service was correctly imported into the framework by the RSA, the getImportedEndPoints() method returns an empty collection. The debugger showed that the endpoint does get added, it just seems that it's done asynchronously and that the EventHook accesses the imported enpoints before the RSA is able to add them.
I opened a bug report. [1]
 
 I'm still a little unclear...do you mean the proxy/imported ServiceReference...and finding out what framework exported it?

Exactly.
 
If this is what you mean, how do you mean to 'identify' the framework that exported it?  The reason I ask about this is that there are several pieces of information in the EndpointDescription that *might* satisfy your needs...e.g.

endpoint.id   (in ECF's impl this is the provider-defined 'uri' for the ECF container)
example:  r-osgi://foo.com:9278
also accessed through EndpointDescription.getId()

endpoint.framework.uuid  RSA-specified unique OSGi framework id
example:  70cd3d4b-4931-0010-1b63-d64101cefd5e
also accessed through EndpointDescription.getFrameworkId()

endpoint.service.id   The id of the ServiceReference on the *exporter*
example:  50
also accessed through EndpointDescription.getServiceId()

Are any of these (or their combination) useful for what you have in mind?

Yes, I'll use the framework UUID to do that.
 
 
Note that you can also set the OSGi standard service.pid (a persistent id for your remote service) on remote service export...if your remote service has a persistent id (i.e. one that is durable over framework restarts).  You can then detect/filter/use this service.pid.  Also...you can explicitly set any custom property on exported remote service...and then use that for your application.

Another question...once you have the identification information you are looking for...how do you wish to use them?  Reason I ask:  If you want to control the import and export yourself, then it would be best to just create your own topology manager.

The information is mainly used for managing purposes. Like I explained above I have multiple instances of the same service. By knowing where each instance is, it's possible to assign them different tasks. For example to achieve some kind of load balancing.

I'm still playing around with the idea to actually control the import and export myself. It might be beneficial to ditch some of the components I created in favor of a TopologyManager. That could lead to the need of mapping ServiceReferences to their exporting framework disappear altogether, because I import the services myself and therefor know where they are.

Thank you for the answers,
Patrick


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=342113
usoPreviewPopup

Back to the top