[jira] [Created] (FELIX-4735) Cannot create a new factory configuration from Web Admin Console
Valentin Valchev created FELIX-4735: --- Summary: Cannot create a new factory configuration from Web Admin Console Key: FELIX-4735 URL: https://issues.apache.org/jira/browse/FELIX-4735 Project: Felix Issue Type: Bug Components: Web Console Reporter: Valentin Valchev Assignee: Valentin Valchev Priority: Blocker Fix For: webconsole-4.2.6 The + button on any factory configuration doesn't work. So basically you are unable to create a new factory config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-4735) Cannot create a new factory configuration from Web Admin Console
[ https://issues.apache.org/jira/browse/FELIX-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev resolved FELIX-4735. - Resolution: Fixed fixed in svn rev. 1646649 > Cannot create a new factory configuration from Web Admin Console > > > Key: FELIX-4735 > URL: https://issues.apache.org/jira/browse/FELIX-4735 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.4 >Reporter: Valentin Valchev >Assignee: Valentin Valchev >Priority: Blocker > Fix For: webconsole-4.2.6 > > > The + button on any factory configuration doesn't work. So basically you are > unable to create a new factory config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4735) Cannot create a new factory configuration from Web Admin Console
[ https://issues.apache.org/jira/browse/FELIX-4735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentin Valchev updated FELIX-4735: Affects Version/s: webconsole-4.2.4 > Cannot create a new factory configuration from Web Admin Console > > > Key: FELIX-4735 > URL: https://issues.apache.org/jira/browse/FELIX-4735 > Project: Felix > Issue Type: Bug > Components: Web Console >Affects Versions: webconsole-4.2.4 >Reporter: Valentin Valchev >Assignee: Valentin Valchev >Priority: Blocker > Fix For: webconsole-4.2.6 > > > The + button on any factory configuration doesn't work. So basically you are > unable to create a new factory config. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253147#comment-14253147
]
Valentin Valchev commented on FELIX-4734:
-
IMHO the web console shouldn't way at all, but you might be right, that it's
more convenient that way.
Looking at the code, I think that web console waits all the time, but that
completely unnecessary for install, start, stop..
But for sure - we should wait for refresh(bundle) and refreshPackages and
probably update(bundle). And blind waiting is really not enough. So I'll think
about it and propose a patch.
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4728) InstanceManager concurrency issue
[ https://issues.apache.org/jira/browse/FELIX-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253195#comment-14253195 ] Niels Beekman commented on FELIX-4728: -- Thanks for the quick fix. Has a release date for 1.12.1 been set yet? I think much of the InstanceManager code would benefit a lot from using modern synchronization classes such as ConcurrentMap rather than a crude Collections.synchronizedMap(). I don't know much about iPOJO internals, but this code path seems to be occurring for each and every dependency access. Is there a limitation on JVM version that prevents iPOJO from being able to use these? > InstanceManager concurrency issue > - > > Key: FELIX-4728 > URL: https://issues.apache.org/jira/browse/FELIX-4728 > Project: Felix > Issue Type: Bug > Components: iPOJO >Affects Versions: ipojo-runtime-1.11.2 >Reporter: Niels Beekman >Assignee: Clement Escoffier > Fix For: ipojo-runtime-1.12.1 > > > We observed a race condition in InstanceManager.onEntry. This is caused by > improperly synchronized access on a HashMap. Unlike reported in FELIX-3500, > we did not get an exception, but high cpu usage due to the data race. See the > relevant thread stacks in the comments. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Felix Web Console UPnP Plugin 1.0.4
+1 Carsten Am 16.12.14 um 13:18 schrieb Valentin Valchev: > Call for a vote on Apache Felix Web Console UPnP Plugin 1.0.4 > > Staging repository available at > https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.upnp/1.0.4/ > > Release Notes - Felix - Version webconsole-upnp-plugin-1.0.4 > > --- > > ** Bug > * [FELIX-3589] - The service id link for UPnP devices doesn't work > * [FELIX-3595] - NPE in ControlServlet.addingService > * [FELIX-3669] - NPE in ControlServlet.deviceToJSON > * [FELIX-4012] - Sometimes the UPnP plugin fails to start due to > device being removed from network > * [FELIX-4013] - Incorrect usage of ServiceTracker.size() in UPnP Plugin > * [FELIX-4032] - UPnP Plugin small refactoring > * [FELIX-4560] - Unsynchonized access to map can cause infinite loop > in UPnP web console plugin > * [FELIX-4733] - UPnP plugin native2ascii plugin conflicts with > Eclipse m2e > > > ** Improvement > * [FELIX-3861] - Set felix.webconsole.category on Web Console plugins > * [FELIX-4016] - Provide more meta data to the UPnP action arguments > > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1046 /tmp/felix-staging > > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > > Best regards, > Valentin Valchev > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix Web Console Event Plugin 1.1.2
+1 Carsten Am 16.12.14 um 13:13 schrieb Valentin Valchev: > Call for a vote on Apache Felix Web Console Event Plugin 1.1.2 > > Staging repository available at > > https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.event/1.1.2/ > > Release Notes - Felix - Version webconsole-event-plugin-1.1.2 > > --- > > ** Bug > * [FELIX-4573] - Web Console Event plugin might cease operation if Event > property is null > * [FELIX-4731] - Event plugin native2ascii plugin conflicts with Eclipse > * [FELIX-4732] - Web Console event plugin is not compatible with > OSGi/Minimum EE > > ** New Feature > * [FELIX-4499] - BundleEventConverter reports UNINSTALLED for UNRESOLVED > events > * [FELIX-4500] - EventListener should implement SynchronousBundleListener > > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1046 /tmp/felix-staging > > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > > Best regards, > Valentin Valchev > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Apache Felix Web Console User Admin Plugin 1.0.0
+1 Carsten Am 16.12.14 um 13:16 schrieb Valentin Valchev: > Call for a vote on Apache Felix Web Console User Admin Plugin 1.0.0 > > Staging repository available at > https://repository.apache.org/content/groups/staging/org/apache/felix/org.apache.felix.webconsole.plugins.useradmin/1.0.0/ > > Release Notes - Felix - Version webconsole-useradmin-plugin-1.0.0 > > --- > > ** Bug > * [FELIX-3633] - User Admin Plugin - no German translation > * [FELIX-3634] - User Admin Plugin - no Russian translation > > ** Improvement > * [FELIX-2254] - User Admin Plugin > * [FELIX-3861] - Set felix.webconsole.category on Web Console plugins > * [FELIX-4703] - User Admin plugin should use all available to the > JVM crypto algorithms > > > You can use this UNIX script to download the release and verify the > signatures: > http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh > > Usage: > sh check_staged_release.sh 1046 /tmp/felix-staging > > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Veto the release (please provide specific comments) > > This vote will be open for 72 hours. > > > Best regards, > Valentin Valchev > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253374#comment-14253374 ] Felix Meschberger commented on FELIX-4692: -- [~cziegeler] For the reasons stated by [~rickhall] I would not apply the patch yet. Looking at the code, it really *is* strange that this patch exhibits such a dramatic improvement. I wanted to find out, what actually is going on in the indexed capability set which really should have a quick (or almost as quick) exit as my patch. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208081#comment-14208081 ] Richard S. Hall edited comment on FELIX-4692 at 12/19/14 1:43 PM: -- Did you investigate whether or not there was something that could be modified in the lookup path to improve performance. If the service lookup is being done by className and no filter, then I would expect that this would be reasonably straightforward since internally the ServiceRegistry.getServiceReferences() method converts this to internal filter format (i.e., no parsing is required) and then does a CapabilitySet.match() with the filter that should immediately hit the index for objectClass and return the matching result. It would be interesting to know where it was spending its time to see if there was a general fix for the issue. Perhaps there is no general fix and it is just the mechanics of doing it generically that causes the slow down, but it would be nice to know more precisely. was (Author: rickhall): Did you investigate whether or not there was something that could be modified in the lookup path to improve performance. If the service lookup is being done by className and no filter, then I would expect that this would be reasonably straightforward since internally the ServiceRegistry.getServiceReferences() method converts this to internal filter format (i.e., no parsing is required) and then does a CapabilitySet.match() with the filter that should immediately it the index for objectClass and return the matching result. It would be interesting to know where it was spending its time to see if there was a general fix for the issue. Perhaps there is no general fix and it is just the mechanics of doing it generically that causes the slow down, but it would be nice to know more precisely. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Native CT Tests passing
On 12/18/14 18:05 , Bob Paulin wrote: All, I resolved the rest of the native code CT test failures in https://issues.apache.org/jira/browse/FELIX-4729. So looks like we're getting close to being ready for R6. Please let me know if there is any feedback on the implementation. A couple of thoughts on the native code I'd like to float prior to the release. 1) R4LibraryClause and R4Library are no longer really R4 at all. Can we consider renaming these classes to NativeLibraryClause and NativeLibrary. I realize this is a bit of a breaking change if developers are using the R4Library and R4LibraryClause classes but I couldn't find any examples of this outside the framework project. The R6 changes might be worth a major revision bump. Yeah, I think renaming them is fine...that is purely legacy. Technically, this isn't public API, so we might not have to worry about it, but I don't really have a strong opinion. 2) Processor and OS Name aliasing: in memory lookup vs coding. R6 has it where the processor and os name gets aliased to potentially many names. Equinox currently does the aliasing by pulling a file into memory. I found it to be more direct and likely more backwards compatable in felix to hook into the normalization process and then do the aliasing. However we could refactor to put all the aliases in a table like Equinox at the expense of some memory. A file might be easier to maintain going forward as new os and processors come out. Might be good to provide some sort of hooks so developers can do this without us if needed. I assume you mean something like this: https://issues.apache.org/jira/browse/FELIX-3883 I think we should move this into configuration. We could define the default values in default.properties and then allow these defaults to be extended in config.properties, for example. 3) Moving from the Felix version of VersionRange to the org.osgi.framework.VersionRange. Currently we have our on VersionRange class with similar but not exactly the same functionality as the org.osgi.framework.VersionRange. It would be helpful if the osgi VersionRange implemented Comparable as we could then remove the special code I had to add to the CapabilitySet class to deal with VersionRange based on the provided OS Version. Not sure if this is something we might consider suggesting in a future spec. If it works for us, then it makes sense to reuse it. Our VersionRange doesn't implement comparable...I don't actually see how a version range could be comparable, since the notion of greater than/less than doesn't really make sense. -> richard Happy Holidays, - Bob
[jira] [Updated] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentin Valchev updated FELIX-4734:
Attachment: FELIX-4734.patch
I'm attaching a patch that:
- removes all unnecessary waits
- always waits for refresh package to complete
-- at most 5 seconds for a single bundle packages refresh
-- at most 15 seconds for the whole framework packages refresh
- it doesn't uses the wiring, since I'm trying to keep webconsole OSGi 4.0
compliant
I didn't make update to do refresh packages. Considering that web console is
developer tool, for me it's better to update the bundle(s) I need, and then to
refresh the packages.
Looking forward for your review.
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253471#comment-14253471
]
Valentin Valchev commented on FELIX-4734:
-
FELIX-600 is somehow related to this issue
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253481#comment-14253481
]
Carsten Ziegeler commented on FELIX-4734:
-
[~v_valchev] Patch lgtm and I agree to not use the wiring api; and I also agree
to not change the behaviour of the "refresh packages" button. Thanks
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4734) Web Console RESTful API should wait for asynchonous operations until they complete
[
https://issues.apache.org/jira/browse/FELIX-4734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14253595#comment-14253595
]
Felix Meschberger commented on FELIX-4734:
--
Please make sure to not cause deadlocks ! We had situations in the past where
the web console bundle itself was involved in the update and refreshPackage
operations and when not properly handling this, this may cause a deadlock !
> Web Console RESTful API should wait for asynchonous operations until they
> complete
> ---
>
> Key: FELIX-4734
> URL: https://issues.apache.org/jira/browse/FELIX-4734
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-4.2.4
>Reporter: Konrad Windszus
> Attachments: FELIX-4734.patch
>
>
> Currently the RESTful API
> (http://felix.apache.org/documentation/subprojects/apache-felix-web-console/web-console-restful-api.html)
> adds a delay of 800ms to the response to give the asynchronous operations
> enough time to complete successfully
> (https://github.com/apache/felix/blob/trunk/webconsole/src/main/java/org/apache/felix/webconsole/internal/core/BundlesServlet.java#L412).
> Instead the according listeners should be used which are notified upon
> completion of an asynchronous task.
> For {{refresh}} {{FrameworkWiring.refreshBundles}} can be used
> (http://www.osgi.org/javadoc/r4v43/core/org/osgi/framework/wiring/FrameworkWiring.html#refreshBundles%28java.util.Collection,%20org.osgi.framework.FrameworkListener...%29).
> A similar approach should be used for the other actions like uninstall,
> install, update, start, stop, ...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4692) Improve Service access time
[ https://issues.apache.org/jira/browse/FELIX-4692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14254007#comment-14254007 ] Richard S. Hall commented on FELIX-4692: Looking at the code of CapabilitySet.match(Set<> caps, SimpleFilter sf) on line 239 we do "matches.retainAll(caps)" which in your case caps would be your 10k services, so I expect that this is where you see the slowdown. We have to do the retainAll() because it gives us the intersection of matches from the index and all other capabilities that have been matched by any other part of the filter up until this point (i.e., since this is recursive due to expression nesting). However, it is certainly the case that the very first time through (i.e., at the top level), we don't need to do retainAll() because by definition caps would already be m_capSet, which is all available capabilities. So, perhaps the simple optimization is to simply check if (caps == m_capSet) and if so don't do retain all. > Improve Service access time > --- > > Key: FELIX-4692 > URL: https://issues.apache.org/jira/browse/FELIX-4692 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-4.4.1 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: framework-4.6.0 > > Attachments: FELIX-4692.diff > > > Currently the ServiceRegistry takes roughly 1ms to access a single service. > In a reasonably large system, this may over time consume considerable time. > For example in our inhouse system sporting roughly 5000 services with 15'000 > service accesses during startup, these accesses acount for almost 15 seconds > or roughly 25-30% of the total startup time. > Internally all accesses to services are handled with a Filter even if the > service is simply retrieved with the service name without a filter. This > causes a considerable overhead. > A simple improvement is to keep services not only in a global Capabitliy Set > accessible through generic filters but also keep such a set for each > registered service name. > The measured improvement of this change is substantial: accessing these > 15'000 services now only takes roughly 3 seconds or 0.2 ms per service or 5 > times faster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
