[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547851#comment-15547851
]
Fabian Lange commented on FELIX-5247:
-
yes that would be the ideal situation, but I feel not comfortable enough to
propose such patch to felix framework.
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServiceImpl.java:364
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547843#comment-15547843
]
Guillaume Nodet commented on FELIX-5247:
One simple way would be to add a configuration flag to configure the
parallelism. If such a flag is set, the StatefulResolver would use
new ResolverImpl(m_logger, parallelism).
If parallelism == 1, no threads will be created at all.
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServiceImpl
Re: [VOTE] Release Apache Felix Http Base 3.0.14, Http Bridge 3.0.14, and Http Jetty 3.3.0
Karl Pauls wrote > Hm, I think we are running into on of the NOTICE in the root of the bundle > svn issues again. > > Both, Bridge and Jetty do not get their NOTICE copied into their binary jar > causing the somewhat awkward situation that the source artifacts have a > NOTICE claiming they contain code from the OSGi Alliance and from Mortbay > but they really don't - while the binary artifacts have a NOTICE that > doesn't mention neither but they actually do contain classes from both. > > IIRC, the solution is to use the append-resources for the NOTICE and than > it should work correctly. As with other cases, I personally think that is a > -1 as I don't like shipping binaries which violate licenses but I can live > with being overruled by the majority provided we fix this in trunk. > @Karl: I've correct this now in trunk, bridge contains only OSGi code, and http.jetty code from OSGi and Eclipse All is licensed under Apache 2.0, so no need for a NOTICE, but I listed everything in the DEPENDENCIES file. Could you please verify that everything looks good now? Thanks Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [DISCUSS] Persistent wiring framework
I came up with the following extension: https://github.com/apache/karaf/blob/master/features/extension/src/main/java/org/apache/karaf/features/extension/Activator.java It seems to work correctly so far. I suppose it would be even faster to have it in the framework to avoid going through the resolver at all, but it seems to fulfill my needs. 2016-10-03 18:02 GMT+02:00 Guillaume Nodet : > I have a use case where the wiring is a bit complicated. > Karaf uses the felix resolver to compute the full wiring and then applies > it. > At this point, all the bundles are resolved and started correctly. > If Karaf is restarted, the framework restarts and resolves the bundles on > its own, using a bad solution (because the resolver is not greedy) which > leaves some bundles in a non resolvable state (i.e. without refreshing some > bundles). > At this point, I've tried to have Karaf stores the computed wiring so that > it can be re-applied when restarting. Unfortunately, in my very case, the > wiring is done in such a way that nearly all bundles needs to be refreshed, > even the one containing the bundle hook, so that's bound to deadlocks and > various problems. > > I'm left with two solutions : > * implement a framework extension to minimize the chances to have to > refresh the bundle containing the resolver hook > * implement a persistent resolution in felix > > I don't mind either way, but I wonder if instead of implementing it in > Karaf, it could be done in the framework in a slightly more robust way > (i.e. not contained in a bundle which itself is bound to refreshes, etc...) > and may be reused by others. > > Thoughts ? > > Guillaume > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ > > -- Guillaume Nodet Red Hat, Open Source Integration Email: gno...@redhat.com Web: http://fusesource.com Blog: http://gnodet.blogspot.com/
[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547797#comment-15547797
]
Fabian Lange commented on FELIX-5247:
-
actually there is another resolver created here:
https://github.com/apache/felix/blob/trunk/framework/src/main/java/org/apache/felix/framework/StatefulResolver.java#L96
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServiceImpl.java:364
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.
[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15547748#comment-15547748
]
Fabian Lange commented on FELIX-5247:
-
you are correct, the org.apache.felix.resolver.Activator.start(BundleContext)
needs to configure an executor to fix this issue.
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServiceImpl.java:364
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545586#comment-15545586
]
Dmitry Konstantinov commented on FELIX-5247:
yes, I think changes are related to
https://issues.apache.org/jira/browse/KARAF-4748 touch only Karaf usage of
Resolver (on subsystems and features level) and will not help to control
threads number are used to resolve OSGi bundles
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServ
[jira] [Commented] (FELIX-5247) Reduce number of threads created by Resolver during a startup of OSGi-based applications
[
https://issues.apache.org/jira/browse/FELIX-5247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15545246#comment-15545246
]
Fabian Lange commented on FELIX-5247:
-
actually I might be mistaken, because the change should also affect this
registration:
https://github.com/apache/felix/blob/trunk/resolver/src/main/java/org/apache/felix/resolver/Activator.java#L43
> Reduce number of threads created by Resolver during a startup of OSGi-based
> applications
>
>
> Key: FELIX-5247
> URL: https://issues.apache.org/jira/browse/FELIX-5247
> Project: Felix
> Issue Type: Improvement
> Components: Framework, Resolver
>Affects Versions: framework-5.4.0, resolver-1.8.0
>Reporter: Dmitry Konstantinov
> Labels: performance
> Attachments: karaf_thread_creation.png
>
>
> Thread creation is a quite expensive operation, so it make sense to reuse
> threads in ResolverImpl if they are needed to split some task and do it in
> parallel.
> For example: Apache Karaf startup with several features can install about 300
> bundles. If each one will create Runtime.getRuntime().availableProcessors()
> threads - so, during a startup about 1000 threads will be created only by
> Resolver (in case of a server machine even much more). Thread creation takes
> let's say (depends on machine, JDK, OS, etc) about 10-20 ms, so we are
> spending about 1-2 seconds of startup time only to create some threads.
> it make sense to create a thread pool once (with a configurable thread
> number) and reuse it for resolving of different bundles.
> Threads creation, stack examples:
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl$1Computer.run() ResolverImpl.java:1150
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor$1.run()
> ResolverImpl.java:2442
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> ThreadPoolExecutor.java:1142
> java.util.concurrent.ThreadPoolExecutor$Worker.run()
> ThreadPoolExecutor.java:617
> java.lang.Thread.run() Thread.java:745
> {noformat}
> {noformat}
> java.lang.Thread.(ThreadGroup, Runnable, String, long) Thread.java
> java.util.concurrent.Executors$DefaultThreadFactory.newThread(Runnable)
> Executors.java:613
> java.util.concurrent.ThreadPoolExecutor$Worker.(ThreadPoolExecutor,
> Runnable) ThreadPoolExecutor.java:612
> java.util.concurrent.ThreadPoolExecutor.addWorker(Runnable, boolean)
> ThreadPoolExecutor.java:925
> java.util.concurrent.ThreadPoolExecutor.execute(Runnable)
> ThreadPoolExecutor.java:1357
> org.apache.felix.resolver.ResolverImpl$EnhancedExecutor.execute(Runnable)
> ResolverImpl.java:2436
> org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(Executor,
> ResolverImpl$ResolveSession, Candidates, Collection) ResolverImpl.java:1158
> org.apache.felix.resolver.ResolverImpl.checkConsistency(Executor,
> ResolverImpl$ResolveSession, List, List, Candidates, Map, Map, boolean)
> ResolverImpl.java:471
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext, Executor)
> ResolverImpl.java:347
> org.apache.felix.resolver.ResolverImpl.resolve(ResolveContext)
> ResolverImpl.java:158
> org.apache.felix.framework.StatefulResolver.resolve(Set, Set)
> StatefulResolver.java:431
> org.apache.felix.framework.Felix.resolveBundleRevision(BundleRevision)
> Felix.java:4118
> org.apache.felix.framework.Felix.startBundle(BundleImpl, int) Felix.java:2124
> org.apache.felix.framework.BundleImpl.start(int) BundleImpl.java:998
> org.apache.felix.framework.BundleImpl.start() BundleImpl.java:984
> org.apache.karaf.features.internal.FeaturesServiceImpl.startBundle(InstallationState,
> Bundle) FeaturesServiceImpl.java:520
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(Set,
> EnumSet) FeaturesServiceImpl.java:478
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(Feature,
> EnumSet) FeaturesServiceImpl.java:419
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> String, EnumSet) FeaturesServiceImpl.java:394
> org.apache.karaf.features.internal.FeaturesServiceImpl.installFeature(String,
> EnumSet) FeaturesServiceImpl.java:364
> {noformat}
--
This message w
Re: [DISCUSS] Release new gogo runtime / jline bundles
On 10/4/16 04:13 , Guillaume Nodet wrote:
2016-10-04 9:16 GMT+02:00 David Bosschaert :
Hi Guillaume,
Does gogo-runtime have a dependency on gogo-jline or will it work without?
Just trying to understand what Java 7 users will be able to do/are missing
without gogo-jline...
No, the dependency is from gogo-jline to gogo-runtime. The gogo-runtime
bundle can be used with gogo-shell or gogo-jline (they are doing the same
thing, but differently).
So JDK7 users can use gogo-runtime + gogo-shell, while JDK8 users can use
gogo-runtime + gogo-jline.
On the version number, if the refactoring was just a change of internal
implementation details without any API changes then, even though there may
be a lot of changes version 0.17.1 would even be ok :)
OTOH when going to version 1.0 I think we're more making a statement: "this
is a good, maintained release" - versions 0.x are generally considered
experimental I think. So I think this is a good thing to do so I would +1
for 1.0.
Yes, I know the usual sematics behind 0.x versions. But I agree, at some
point,
it does not make sense to stay on 0.x forever.
So unless somone objects, I'll go for 1.0 for both gogo-runtime and
gogo-jline and their packages.
I think we could also get rid of the status="provisional";
mandatory:="status" stuff on the packages which does not make sense
anymore.
The only reason why that was done in the first place was because there
was provisional OSGi API per our policy. However, if there is no longer
OSGi API in it, then yeah it definitely doesn't make sense anymore.
-> richard
Cheers,
David
On 3 October 2016 at 09:30, Guillaume Nodet wrote:
I've downgraded the requirement or the gogo-runtime to java 7.
That's not really possible for the gogo-jline bundle which has a
dependency
on jline requiring java 8 atm.
Given the amount of change, I think it would be better to bump the
gogo-runtime bundle version. Given it's currently at 0.17, what should
it
be then ? Bump to 1.0 ?
2016-09-28 10:52 GMT+02:00 David Bosschaert
I think it would be great to finally get the improved gogo shell
released
in Felix. Personally I don't really need Java 7 support, but it might
be
good to allow this to enable wider adoption. If we support Java 7 we
might
be able to replace the default shell in the Felix Framework download
with
this improved one. It might be harder to replace the default if it
requires
Java 8...
I'm not entirely sure - what do people think, will we replace the
default
shell in the framework with this new gogo shell? And if so, will Java 8
be
ok?
Thanks,
David
On 28 September 2016 at 01:40, David Jencks
wrote:
I don’t recall too well…. IIRC line requires java 8. Does the rest
of
gogo now also require java 8?
thanks
david jencks
On Sep 27, 2016, at 3:02 PM, Guillaume Nodet
wrote:
I'd like to release the big changes pending in gogo runtime and
gogo
jline
bundles.
Given there are some big changes in the runtime (the jline one is a
new
bundle, so it does not matter so much), I'd like to give people
some
time
to review the changes.
I'd like to do the release next week if there's no concerns.
Some of the new features from gogo runtime:
* better parser
* support for redirections
* support for jobs
* advanced parameter expansion (such as ${(GL)it/_/-})
Features provided by the new gogo jline bundle (similar to the gogo
shell,
but using jline + leveraging the new runtime features):
* better terminal support
* full line editing
* completion
* syntax highlighting
* multi line edition
Note that those bundles can also be run outside osgi (jline +
gogo-runtime
+ gogo-jline). I'm using the following command line to launch
those
from
the felix/gogo directory:
java -cp
/Users/gnodet/.m2/repository/org/jline/jline/3.0.0.M2/
jline-3.0.0.M2.jar:runtime/target/org.apache.felix.gogo.
runtime-0.17.0-SNAPSHOT.jar:jline/target/org.apache.felix.
gogo.jline-0.1.0-SNAPSHOT.jar
org.apache.felix.gogo.jline.Main
Cheers,
Guillaume Nodet
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
[jira] [Commented] (FELIX-5261) FileInstall: allow comments in *.config files
[ https://issues.apache.org/jira/browse/FELIX-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15544990#comment-15544990 ] Ferry Huberts commented on FELIX-5261: -- Ok, investigated these changes: org.osgi.service.cm 1.3 --> 1.5 = OSGi 4.2 --> 5.0 org.osgi.util.tracker 1.4 --> 1.5 = OSGi 4.2 --> 4.3 Can you guys PLEASE PLEASE PLEASE do a release of FileInstall? > FileInstall: allow comments in *.config files > - > > Key: FELIX-5261 > URL: https://issues.apache.org/jira/browse/FELIX-5261 > Project: Felix > Issue Type: Improvement > Components: File Install >Affects Versions: fileinstall-3.5.4 > Environment: All >Reporter: Ferry Huberts >Assignee: Guillaume Nodet > Fix For: fileinstall-3.5.6 > > > Previous updates to ConfigAdmin forgot to update FileInstall. > FileInstall only uses a single class from ConfigAdmin, but upgrading that > dependency to the latest ConfigAdmin enables comments in *.config files. > This enables me to get rid of all the *.config.txt files in my project (that > are used to document for users what options are available) > I have already summitted a PR on GitHub: > https://github.com/apache/felix/pull/67 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Release new gogo runtime / jline bundles
2016-10-04 9:16 GMT+02:00 David Bosschaert :
> Hi Guillaume,
>
> Does gogo-runtime have a dependency on gogo-jline or will it work without?
> Just trying to understand what Java 7 users will be able to do/are missing
> without gogo-jline...
>
No, the dependency is from gogo-jline to gogo-runtime. The gogo-runtime
bundle can be used with gogo-shell or gogo-jline (they are doing the same
thing, but differently).
So JDK7 users can use gogo-runtime + gogo-shell, while JDK8 users can use
gogo-runtime + gogo-jline.
>
> On the version number, if the refactoring was just a change of internal
> implementation details without any API changes then, even though there may
> be a lot of changes version 0.17.1 would even be ok :)
>
> OTOH when going to version 1.0 I think we're more making a statement: "this
> is a good, maintained release" - versions 0.x are generally considered
> experimental I think. So I think this is a good thing to do so I would +1
> for 1.0.
>
Yes, I know the usual sematics behind 0.x versions. But I agree, at some
point,
it does not make sense to stay on 0.x forever.
So unless somone objects, I'll go for 1.0 for both gogo-runtime and
gogo-jline and their packages.
I think we could also get rid of the status="provisional";
mandatory:="status" stuff on the packages which does not make sense
anymore.
>
> Cheers,
>
> David
>
> On 3 October 2016 at 09:30, Guillaume Nodet wrote:
>
> > I've downgraded the requirement or the gogo-runtime to java 7.
> > That's not really possible for the gogo-jline bundle which has a
> dependency
> > on jline requiring java 8 atm.
> >
> > Given the amount of change, I think it would be better to bump the
> > gogo-runtime bundle version. Given it's currently at 0.17, what should
> it
> > be then ? Bump to 1.0 ?
> >
> > 2016-09-28 10:52 GMT+02:00 David Bosschaert >:
> >
> > > I think it would be great to finally get the improved gogo shell
> released
> > > in Felix. Personally I don't really need Java 7 support, but it might
> be
> > > good to allow this to enable wider adoption. If we support Java 7 we
> > might
> > > be able to replace the default shell in the Felix Framework download
> with
> > > this improved one. It might be harder to replace the default if it
> > requires
> > > Java 8...
> > >
> > > I'm not entirely sure - what do people think, will we replace the
> default
> > > shell in the framework with this new gogo shell? And if so, will Java 8
> > be
> > > ok?
> > >
> > > Thanks,
> > >
> > > David
> > >
> > > On 28 September 2016 at 01:40, David Jencks > > invalid>
> > > wrote:
> > >
> > > > I don’t recall too well…. IIRC line requires java 8. Does the rest
> of
> > > > gogo now also require java 8?
> > > >
> > > > thanks
> > > > david jencks
> > > >
> > > >
> > > > > On Sep 27, 2016, at 3:02 PM, Guillaume Nodet
> > > wrote:
> > > > >
> > > > > I'd like to release the big changes pending in gogo runtime and
> gogo
> > > > jline
> > > > > bundles.
> > > > > Given there are some big changes in the runtime (the jline one is a
> > new
> > > > > bundle, so it does not matter so much), I'd like to give people
> some
> > > time
> > > > > to review the changes.
> > > > >
> > > > > I'd like to do the release next week if there's no concerns.
> > > > >
> > > > > Some of the new features from gogo runtime:
> > > > > * better parser
> > > > > * support for redirections
> > > > > * support for jobs
> > > > > * advanced parameter expansion (such as ${(GL)it/_/-})
> > > > > Features provided by the new gogo jline bundle (similar to the gogo
> > > > shell,
> > > > > but using jline + leveraging the new runtime features):
> > > > > * better terminal support
> > > > > * full line editing
> > > > > * completion
> > > > > * syntax highlighting
> > > > > * multi line edition
> > > > >
> > > > > Note that those bundles can also be run outside osgi (jline +
> > > > gogo-runtime
> > > > > + gogo-jline). I'm using the following command line to launch
> those
> > > from
> > > > > the felix/gogo directory:
> > > > >
> > > > > java -cp
> > > > > /Users/gnodet/.m2/repository/org/jline/jline/3.0.0.M2/
> > > > jline-3.0.0.M2.jar:runtime/target/org.apache.felix.gogo.
> > > > runtime-0.17.0-SNAPSHOT.jar:jline/target/org.apache.felix.
> > > > gogo.jline-0.1.0-SNAPSHOT.jar
> > > > > org.apache.felix.gogo.jline.Main
> > > > >
> > > > > Cheers,
> > > > > Guillaume Nodet
> > > >
> > > >
> > >
> >
> >
> >
> > --
> >
> > Guillaume Nodet
> >
> > Red Hat, Open Source Integration
> >
> > Email: gno...@redhat.com
> > Web: http://fusesource.com
> > Blog: http://gnodet.blogspot.com/
> >
>
--
Guillaume Nodet
Red Hat, Open Source Integration
Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/
Re: [DISCUSS] Release new gogo runtime / jline bundles
Hi Guillaume,
Does gogo-runtime have a dependency on gogo-jline or will it work without?
Just trying to understand what Java 7 users will be able to do/are missing
without gogo-jline...
On the version number, if the refactoring was just a change of internal
implementation details without any API changes then, even though there may
be a lot of changes version 0.17.1 would even be ok :)
OTOH when going to version 1.0 I think we're more making a statement: "this
is a good, maintained release" - versions 0.x are generally considered
experimental I think. So I think this is a good thing to do so I would +1
for 1.0.
Cheers,
David
On 3 October 2016 at 09:30, Guillaume Nodet wrote:
> I've downgraded the requirement or the gogo-runtime to java 7.
> That's not really possible for the gogo-jline bundle which has a dependency
> on jline requiring java 8 atm.
>
> Given the amount of change, I think it would be better to bump the
> gogo-runtime bundle version. Given it's currently at 0.17, what should it
> be then ? Bump to 1.0 ?
>
> 2016-09-28 10:52 GMT+02:00 David Bosschaert :
>
> > I think it would be great to finally get the improved gogo shell released
> > in Felix. Personally I don't really need Java 7 support, but it might be
> > good to allow this to enable wider adoption. If we support Java 7 we
> might
> > be able to replace the default shell in the Felix Framework download with
> > this improved one. It might be harder to replace the default if it
> requires
> > Java 8...
> >
> > I'm not entirely sure - what do people think, will we replace the default
> > shell in the framework with this new gogo shell? And if so, will Java 8
> be
> > ok?
> >
> > Thanks,
> >
> > David
> >
> > On 28 September 2016 at 01:40, David Jencks > invalid>
> > wrote:
> >
> > > I don’t recall too well…. IIRC line requires java 8. Does the rest of
> > > gogo now also require java 8?
> > >
> > > thanks
> > > david jencks
> > >
> > >
> > > > On Sep 27, 2016, at 3:02 PM, Guillaume Nodet
> > wrote:
> > > >
> > > > I'd like to release the big changes pending in gogo runtime and gogo
> > > jline
> > > > bundles.
> > > > Given there are some big changes in the runtime (the jline one is a
> new
> > > > bundle, so it does not matter so much), I'd like to give people some
> > time
> > > > to review the changes.
> > > >
> > > > I'd like to do the release next week if there's no concerns.
> > > >
> > > > Some of the new features from gogo runtime:
> > > > * better parser
> > > > * support for redirections
> > > > * support for jobs
> > > > * advanced parameter expansion (such as ${(GL)it/_/-})
> > > > Features provided by the new gogo jline bundle (similar to the gogo
> > > shell,
> > > > but using jline + leveraging the new runtime features):
> > > > * better terminal support
> > > > * full line editing
> > > > * completion
> > > > * syntax highlighting
> > > > * multi line edition
> > > >
> > > > Note that those bundles can also be run outside osgi (jline +
> > > gogo-runtime
> > > > + gogo-jline). I'm using the following command line to launch those
> > from
> > > > the felix/gogo directory:
> > > >
> > > > java -cp
> > > > /Users/gnodet/.m2/repository/org/jline/jline/3.0.0.M2/
> > > jline-3.0.0.M2.jar:runtime/target/org.apache.felix.gogo.
> > > runtime-0.17.0-SNAPSHOT.jar:jline/target/org.apache.felix.
> > > gogo.jline-0.1.0-SNAPSHOT.jar
> > > > org.apache.felix.gogo.jline.Main
> > > >
> > > > Cheers,
> > > > Guillaume Nodet
> > >
> > >
> >
>
>
>
> --
>
> Guillaume Nodet
>
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
