[
https://issues.apache.org/jira/browse/FELIX-5619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028107#comment-16028107
]
Pierre De Rop commented on FELIX-5619:
--------------------------------------
Hi Jeroen,
I have committed a patch which allows you to supply your own FilterIndex
implementation.
(notice that there was also an old jira issue (FELIX-4028) which was also
asking for this).
A new org.apache.felix.dependencymanager.index.itest project has been created
for this new feature (and existing filter index tests that were previously
provided in the org.apache.felix.dependencymanager.itest bundle have been moved
to org.apache.felix.dependencymanager.index.itest bundle).
So, you can supply a FilterIndex implementation in the two following ways:
1) statically:
when you specify the "org.apache.felix.dependencymanager.filterindex" system
property, you can now optionally specify the classname which will be used for a
given index.
The format is the following:
{code}
property-index ::= service-property | service-property ',' property-index
property-index-withclass ::= classname ':' property-index
index ::= '*aspect*' | '*adapter*' | property-index | property-index-withclass
indices ::= index | indices ';' index
{code}
If you supply a classname, it must be part of a bundle which is a fragment of
the org.apache.felix.dependencymanager bundle.
Example:
{code}
org.apache.felix.dependencymanager.filterindex=org.mycompany.index.MyFilterIndex:objectClass,id
{code}
See the following tests for static custom filter indices:
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/static.customindex.bnd
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/src/org/apache/felix/dm/index/itest/staticcustomindex/StaticCustomFilterIndex.java
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/src/org/apache/felix/dm/index/itest/tests/StaticCustomIndexTest.java
2) dynamically:
You can also register in the OSGi service registry your own filter index (using
or not dependency manager API), and it will be registered in the
ServiceRegistryCache.
In this case, you should start your bundle which register your FilterIndex (as
well as the org.apache.felix.dependencymanager bundle) first, before all other
bundles. Else, previously started dm component won't use your filter index.
See the following tests for dynamic custom filter indices:
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/dynamic.customindex.bnd
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/src/org/apache/felix/dm/index/itest/dynamiccustomindex/DynamicCustomFilterIndex.java
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.index.itest/src/org/apache/felix/dm/index/itest/tests/DynamicCustomIndexTest.java
> MultiProperyFilterIndex memory consumption
> ------------------------------------------
>
> Key: FELIX-5619
> URL: https://issues.apache.org/jira/browse/FELIX-5619
> Project: Felix
> Issue Type: Improvement
> Components: Dependency Manager
> Affects Versions: org.apache.felix.dependencymanager-r9
> Reporter: Jeroen Daanen
> Assignee: Pierre De Rop
> Attachments: Filter.java, MultiPropertyFilterIndex.java,
> MultiPropertyFilterIndexPerformanceTest.java,
> MultiPropertyFilterIndexReferencedTest.java, MultiPropertyKey.java,
> MultiPropertyKeyTest.java, TestReference.java
>
>
> In our product using the dependency manager and having configured several
> filter index settings, the memory consumption of the MultiPropertyFilterIndex
> is relatively high because it contains a map of string keys to service
> reference, where the keys are concatenated strings based on the service
> properties. These strings are all newly created objects resulting in
> inefficient memory usage.
> In the attachment you find a version of the index which uses less memory
> because it no longer stores appended strings in new string objects, but
> stores the original strings in string arrays. This way it can benefit for
> instance from the garbage collector deduplicating strings.
> Also attached are some unit tests to ensure the behavior did not change (note
> that we could not find any existing unit tests on the
> MultiPropertyFilterIndex).
> If a large project is configured in our product we could have around 41500
> services total. The configured MultiproperyFilterIndexes then contain more
> then 500000 keys.
> When executing the attached unit test
> 'MultiPropertyFilterIndexPerformanceTest' for 500000 service references we
> found the memory consumption is reduced by 44%:
> Existing implemenation:
> fastest write time: 3.433 milliseconds
> fastest read time: 1.577 milliseconds
> memory consumption: 1374 MB
> New implementation:
> fastest write time: 2.329 milliseconds
> fastest read time: 1.997 milliseconds
> memory consumption: 771 MB
> Would it be either possible to replace the existing implementation or make it
> possible to supply a custom implementation of a filter index to the
> dependency manager?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
