felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcel Offermans (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (FELIX-1546) DM/Temporal Dependency/Bound Service Replacement features
Date Tue, 11 May 2010 09:21:43 GMT

     [ https://issues.apache.org/jira/browse/FELIX-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Marcel Offermans resolved FELIX-1546.

    Resolution: Fixed

Resolving the issue, since temporal dependencies have been added (for some time) now.

> DM/Temporal Dependency/Bound Service Replacement features
> ---------------------------------------------------------
>                 Key: FELIX-1546
>                 URL: https://issues.apache.org/jira/browse/FELIX-1546
>             Project: Felix
>          Issue Type: New Feature
>          Components: Dependency Manager
>            Reporter: Pierre De Rop
>            Assignee: Marcel Offermans
>            Priority: Minor
>         Attachments: DM-1.tgz, DM-2-test.tgz, DM-2.tgz, DM-3.tgz, DM-4.tgz, DM-test.tgz,
> This issue proposes some new features for DM:
> Feature 1): dealing with service dynamics: Temporal dependencies
> ----------------------------------------------------------------
> So far, with DM, when a service looses one of its required dependencies, the service
> deactivated. For stateless required dependencies, it would then be nice to support a
> required dependency, which blocks the caller thread while the dependency is being updated.
> In the attached DM.tgz patch, you will find a new "TemporalServiceDependency.java" class,
which extends the
> "ServiceDependency" class. In TemporalServiceDependency.java, you'll find a setTimeout
> which takes a timeout parameter, in millis, specifying  the max time to wait (30 seconds
> default). After timeout, an unchecked "ServiceUnavailableException" is fired to the caller
> thread. 
> Here is a more specific description of what the new "TemporalServiceDependency" class
is doing
> exactly: 
> The class actually uses a Dynamic Proxy which wraps the actual service dependency
> instance. When the service is lost, we check if there is an available replacement service
from the  
> tracker. If true, then we just update our internal service with the new one. If false,
then we set
> a flag, which blocks any thread that invokes the service through the Dynamic Proxy. On
> we raise an unchecked ServiceUnavailableException, telling that the required service
is unavailable (but we
> don't deactivate the service). The next time the dependency is invoked and if the service
has come
> up, then the method will invoke the new service transparently.
> Using setTimeout(0) is supported: The thread won't be blocked, but will catch the unchecked
> exception immediately, in case of service loss.
> Of course, I don't pretend here to propose a feature as powerful as iPOJO "temporal dependencies"
> or Blueprint specification.  However, you will see that the proposed patch is somewhat
> lightweight and is just fine for Dependency Manager. 
> For example, Here is an example ->
> dm.add(createService()
>        .setImplementation(Client.class)
>        .add(createTemporalServiceDependency()
> 	    .setService(MyService.class) // AutoConfig
> 	    .setTimeout(5000)));
> public class Client implements Runnable {
>   private Thread _thread;
>   private MyService _service; // Dynamic Proxy auto injected (AUTO CONFIG MODE)
>   void start() {
>     _thread = new Thread(this);
>     _thread.start();
>   }
>   public void run() {
>     while (true) {
> 	try { 
> 	  _service.doService(); // will block while myService is updated
> 	} catch (Throwable t) {
> 	  t.printStackTrace(); // ServiceUnavailableException if the service is not here for
more than 5 seconds
> 	}
>     }
>   }
> }
> One last note: this feature is only meaningful for stateless services, not for sateful
> services. But for stateless services, I think that it is cool to not re-activate the
> service while the dependency is updated. For stateful services, I don't think that temporal
> dependencies applies because we would then loose service internal states between updates
> One last note: in TemporalServiceDependency, I override returned type which is only supported
> jdk 1.5.
> For instance, the TemporalServiceDependency.setTimeout is defined as this:
>   public TemporalServiceDependency setTimeout( long timeout ) { ...}
> So, I am wondering if that would be possible to impose jdk 1.5 for the next version of
DM ?
> Feature 2): dealing with Bound Service Replacement:
> ---------------------------------------------------
> We would like DM to be able to replace a lost required dependency, by another existing
one (if
> available from the registry), but without deactivating the service. Currently, the service
> deactivated when loosing one of its required dependencies. If, however, a replacement
> available from tracker, we just would like invoke the "changed" service callback (instead
> deactivating it).
> I know that in DeclarativeService, the "added", then the "removed" callback would be
invoked, but
> I think It's much more intuitive to invoke the "changed" callback.
> For example, when a required service dependency is lost, DM could behave like the following:

> 1- lookup another service (which matches the lost service dependency filter).
> 2- If found, update the service (in AutoConfig mode), or invoke a "changed" callbacks.
> 3- Otherwise, if AutoConfig is turned off and there is no "changed" callback, then deactivate
>    service (like it is the case currently). 
> The fix in located in the ServiceDependency.java (see removedService method).
> Notice that I also changed the makeUnavailable method.
> Feature 3): let the DM shell display service dependencies filters.
> -----------------------------------------------------------------------------
> Currently, the DM shell displays the service dependencies without the service filter.
So that is
> problematic when a service have multiple dependencies on the same service, but with different
> filters.
> For example: when typing the command "dm", the patch is now displaying the following:
> [7] test.dm
>     class test.Client registered
>       test.Printer(color=true) service required available
>       test.Printer(color=false) service required available
> The fix is located in ServiceDependency.java, in the getName() method, which appends
the service
> filter after the service name. Notice that we don't display the 'objectClass' parameter.
> Auto Configuration vs Callbacks
> -------------------------------
> Well this is not a feature, but rather an improvement regarding the issue 
> https://issues.apache.org/jira/browse/FELIX-1278
> Recently, you fixed the issue FELIX-1278, where we asked to turn off autoconf when setCallbacks
is invoked 
> (thank you for the fix !).
> However, I think we forgot to ask you to not turn off autoconfig if both setCallback
> setAutoConfig(true) are invoked. Indeed, in some times, it may make sense to use both
> like this: ->
>    dm.add(createServiceDependency()
> 	  .setService(MyService.class)
> 	  .setRequired(false)
> 	  .setAutoConfig("_field") 
>  	  .setCallbacks("add", "remove"));
> Here, we inject an optional configuration in AutoConfig mode (field injection), but we
> provide a callback method to be able to handle new services (after activation).
> You could tell me that with the current svn fix, we could invoke setCallbacks BEFORE
> setAutoConfig. But I just added a flag when
> setAutoConfig method is called explicitly (in order to avoid turning off auto config
> setCallbacks method). The fix in located in ServideDependency.java
> Regards;
> /pierre

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message