[
https://issues.apache.org/jira/browse/FELIX-1546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774754#action_12774754
]
Pierre De Rop commented on FELIX-1546:
--------------------------------------
Hi Marcel,
just to follow up with this contributed, I attached a slight modified version
of the temporal dependency class, which now supports full concurrency between
service invokers.
I just use read/write lock in oder to allow multiple threads to invoke the
service concurrently, but the updating thread will use the "write" lock in
order to avoid updating the service while in use (Please refer to the javadoc,
I added many comments).
I also moved back regarding the replacement service. in my previous post, I
proposed to add a "replace" callback in ServiceDependency. But this callback is
actually useless, and we can just behave just like with DeclarativeServlce: So,
when a required service can be replaced, I just invoke "added", then "removed"
callback.
I have tested the code a lot, so I think that now it's ready to go commited.
I will let you decide.
thanks;
/pierre
> 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
> Priority: Minor
> Attachments: DM-1.tgz, DM-2-test.tgz, DM-2.tgz, DM-test.tgz, DM.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 is
> deactivated. For stateless required dependencies, it would then be nice to
> support a temporal
> 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 method
> which takes a timeout parameter, in millis, specifying the max time to wait
> (30 seconds by
> 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 timeout,
> 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 whole
> 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 in
> 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 is
> deactivated when loosing one of its required dependencies. If, however, a
> replacement is
> available from tracker, we just would like invoke the "changed" service
> callback (instead of
> 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 the
> 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 methods,
> 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 also
> 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 from
> 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.
