You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2012/12/16 06:03:56 UTC
[DS} major refactoring of dependency management
I've been working on fixing the numerous timing holes in ds dependency tracking and I think I'm getting close to being willing to commit the results.
I've put what I have now up at github at https://github.com/djencks/felix.git in the service-tracker-3 branch. If anyone is interested in taking a look that would be great.
There are two main parts to my refactoring:
1. use a copy of ServiceTracker modified for the requirements of DS. Service tracker actually tracks services properly and doesn't emit duplicate events, miss events, etc etc. I don't think its possible to track services properly in any simpler way. Modifications are primarily:
-a- we need a new Added event after the service is put in the tracking map since we may want to use the event as a trigger to try to activate the component, querying the service tracker for matching services. So the service better be in the map :-)
-b- Closing needs to happen in 2 steps in order to deal with filter changes. The initial close step needs to unregister the service listener and return the current state of the map. The second close step can clear the map.
-c- We need to expose the internal tracker for some locking.
-d- expose the tracking count. This already was in the base tracker code but not used in ServiceTracker. we need it. This is an event counter, not the number of tracked services.
2. For each component instance, keep track of the initial tracking count when we query for existing services and the final tracking count when we unbind services. Then we can ignore, for a given instance, events that are "before" (have a lower tracking count than) the open and "after" (have a higher tracking count than) the close thus avoiding duplicate and missing bind and unbinds.
I also put the different multiplicity/dynamic styles of reference in separate customizer classes which I think simplifies the logic.
There are a few other bug fixes in there too:
FELIX-3729
[DS] Track dependencies by imitating ServiceTracker and keeping a list of actual service references all the time (this is most of the work)
FELIX-3738
[DS] ComponentInstance.getServices(String refName) is implemented wrong for 0..1 and 1..1 refs
FELIX-3825
[DS] make logging more useful by including component ID when known
As a side effect, a lot more of the circular reference situations are getting resolved. I'm not entirely sure why, but I'm not objecting.
There are a lot (?) of unused parts of service tracker. So far I've made minimal modifications to the copied osgi code in the interests of maintainability in case the osgi code changes, but I could easily be talked into removing the stuff we don't use.
thanks
david jencks
Re: [DS} major refactoring of dependency management
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David,
Just to let you know I did some quick testing and I did not find any
regressions.
I think you can commit if you think you are ready.
regards;
/pierre
On Sun, Dec 16, 2012 at 6:03 AM, David Jencks <da...@yahoo.com>wrote:
> I've been working on fixing the numerous timing holes in ds dependency
> tracking and I think I'm getting close to being willing to commit the
> results.
>
> I've put what I have now up at github at
> https://github.com/djencks/felix.git in the service-tracker-3 branch. If
> anyone is interested in taking a look that would be great.
>
> There are two main parts to my refactoring:
>
> 1. use a copy of ServiceTracker modified for the requirements of DS.
> Service tracker actually tracks services properly and doesn't emit
> duplicate events, miss events, etc etc. I don't think its possible to
> track services properly in any simpler way. Modifications are primarily:
> -a- we need a new Added event after the service is put in the tracking map
> since we may want to use the event as a trigger to try to activate the
> component, querying the service tracker for matching services. So the
> service better be in the map :-)
> -b- Closing needs to happen in 2 steps in order to deal with filter
> changes. The initial close step needs to unregister the service listener
> and return the current state of the map. The second close step can clear
> the map.
> -c- We need to expose the internal tracker for some locking.
> -d- expose the tracking count. This already was in the base tracker code
> but not used in ServiceTracker. we need it. This is an event counter, not
> the number of tracked services.
>
> 2. For each component instance, keep track of the initial tracking count
> when we query for existing services and the final tracking count when we
> unbind services. Then we can ignore, for a given instance, events that are
> "before" (have a lower tracking count than) the open and "after" (have a
> higher tracking count than) the close thus avoiding duplicate and missing
> bind and unbinds.
>
> I also put the different multiplicity/dynamic styles of reference in
> separate customizer classes which I think simplifies the logic.
>
> There are a few other bug fixes in there too:
>
> FELIX-3729
> [DS] Track dependencies by imitating ServiceTracker and keeping a list of
> actual service references all the time (this is most of the work)
>
> FELIX-3738
> [DS] ComponentInstance.getServices(String refName) is implemented wrong
> for 0..1 and 1..1 refs
>
> FELIX-3825
> [DS] make logging more useful by including component ID when known
>
>
>
> As a side effect, a lot more of the circular reference situations are
> getting resolved. I'm not entirely sure why, but I'm not objecting.
>
>
> There are a lot (?) of unused parts of service tracker. So far I've made
> minimal modifications to the copied osgi code in the interests of
> maintainability in case the osgi code changes, but I could easily be talked
> into removing the stuff we don't use.
>
>
> thanks
> david jencks
>
>
>
>
Re: [DS} major refactoring of dependency management
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David,
great ! I'll try to do some tests this week.
regards
/Pierre
On Sun, Dec 16, 2012 at 6:03 AM, David Jencks <da...@yahoo.com>wrote:
> I've been working on fixing the numerous timing holes in ds dependency
> tracking and I think I'm getting close to being willing to commit the
> results.
>
> I've put what I have now up at github at
> https://github.com/djencks/felix.git in the service-tracker-3 branch. If
> anyone is interested in taking a look that would be great.
>
> There are two main parts to my refactoring:
>
> 1. use a copy of ServiceTracker modified for the requirements of DS.
> Service tracker actually tracks services properly and doesn't emit
> duplicate events, miss events, etc etc. I don't think its possible to
> track services properly in any simpler way. Modifications are primarily:
> -a- we need a new Added event after the service is put in the tracking map
> since we may want to use the event as a trigger to try to activate the
> component, querying the service tracker for matching services. So the
> service better be in the map :-)
> -b- Closing needs to happen in 2 steps in order to deal with filter
> changes. The initial close step needs to unregister the service listener
> and return the current state of the map. The second close step can clear
> the map.
> -c- We need to expose the internal tracker for some locking.
> -d- expose the tracking count. This already was in the base tracker code
> but not used in ServiceTracker. we need it. This is an event counter, not
> the number of tracked services.
>
> 2. For each component instance, keep track of the initial tracking count
> when we query for existing services and the final tracking count when we
> unbind services. Then we can ignore, for a given instance, events that are
> "before" (have a lower tracking count than) the open and "after" (have a
> higher tracking count than) the close thus avoiding duplicate and missing
> bind and unbinds.
>
> I also put the different multiplicity/dynamic styles of reference in
> separate customizer classes which I think simplifies the logic.
>
> There are a few other bug fixes in there too:
>
> FELIX-3729
> [DS] Track dependencies by imitating ServiceTracker and keeping a list of
> actual service references all the time (this is most of the work)
>
> FELIX-3738
> [DS] ComponentInstance.getServices(String refName) is implemented wrong
> for 0..1 and 1..1 refs
>
> FELIX-3825
> [DS] make logging more useful by including component ID when known
>
>
>
> As a side effect, a lot more of the circular reference situations are
> getting resolved. I'm not entirely sure why, but I'm not objecting.
>
>
> There are a lot (?) of unused parts of service tracker. So far I've made
> minimal modifications to the copied osgi code in the interests of
> maintainability in case the osgi code changes, but I could easily be talked
> into removing the stuff we don't use.
>
>
> thanks
> david jencks
>
>
>
>
Re: [DS} major refactoring of dependency management
Posted by Marcel Offermans <ma...@luminis.nl>.
On Dec 16, 2012, at 6:03 , David Jencks <da...@yahoo.com> wrote:
> 1. use a copy of ServiceTracker modified for the requirements of DS. Service tracker actually tracks services properly and doesn't emit duplicate events, miss events, etc etc. I don't think its possible to track services properly in any simpler way.
Interestingly, for the Dependency Manager I did something similar. I extended ServiceTracker for exactly the same reason initially as you, namely to add a "service added" callback. I then later added some logic to deal with the "aspect services", so probably our implementations don't have exactly the same features. I just wanted to let you know you're not the only one taking this path. :)
Greetings, Marcel