Thanks Pierre for submitting a unit test to FELIX-4866 that helped me
enormously in identifying the issue.
I have fixed the bug in my code (without degrading performance) and at
least your concurrency test, my concurrency tests and all the
framework unit tests now consistently pass. I would be
Yes David, indeed our scenarios are different. In mine, I'm measuring the
assembly of components using parallel dependency manager where components
are concurrently activated, registered, and bound with each other, using a
shared thread pool.
cheers;
/Pierre
On Tue, May 19, 2015 at 3:40 PM,
Hi David,
Excellent.
I'm glad to confirm that the issue is resolved, and my DM loader is now
running seamlessly.
I'm observing an overall gain of 16% compared to the previous 5.0.0.
(but this has to be taken with care,because I only made a quick test).
I did not have time but I guess I could
I just committed the benchmark tool in
http://svn.apache.org/viewvc/felix/sandbox/pderop/loadtest/, if you can
take a look.
To run the scenario:
- install jdk8:
[nxuser@nx0012 pderop]$ java -version
java version 1.8.0_40
Java(TM) SE Runtime Environment (build 1.8.0_40-b26)
Java HotSpot(TM)
Hi Pierre,
I'll take a look today.
Cheers,
David
On 14 May 2015 at 14:00, Pierre De Rop pierre.de...@gmail.com wrote:
I just committed the benchmark tool in
http://svn.apache.org/viewvc/felix/sandbox/pderop/loadtest/, if you can
take a look.
To run the scenario:
- install jdk8:
I think I know what this is. I had some additional changes exactly in
this area that I simply forgot to apply this morning. I should have it
fixed sometime today.
Cheers,
David
On 14 May 2015 at 14:03, David Bosschaert david.bosscha...@gmail.com wrote:
Hi Pierre,
I'll take a look today.
I've fixed this now in svn.apache.org/viewvc?view=revisionrevision=1679367
Pierre, your loadtest now runs to completion - thanks for reporting
this issue! I can see that the results for the parallel tests are a
little bit different than before, but I'm not sure how to read them so
I'll leave the
Thanks David; I just gave a try, and indeed the parallel test passed. I
observed a gain of around 7/10%. The tool is described in [1].
But I only have 4 cores on my laptop and I will make more tests in my lab
at work (next week) where we have some servers having 32 or even 128
processors. This
oops, I just realise that it's not making sense to include the SCR test
bundle in the benchmark tools, since it's not a concurrent test.
So for now, I have clues about where the problem may come from.
cheers;
/Pierre
On Thu, May 14, 2015 at 7:54 PM, Pierre De Rop pierre.de...@gmail.com
wrote:
Hi Pierre,
It would indeed be useful to find out more about why your test is
hanging. Maybe analysing a threaddump might give some more
information?
Cheers,
David
On 14 May 2015 at 19:54, Pierre De Rop pierre.de...@gmail.com wrote:
Thanks David; I just gave a try, and indeed the parallel test
the threadump did not help.
I will investigate (may be a bug somewhere in my part; if this is the
case, I would be sorry to make all this noise).
hope to let you know soon.
by the way, do you know how to run the SCR integration tests with the
framework from the trunk ? I know that there are
ok, it's a bit late, I will continue tomorrow.
What I just found is that when the test fails, we are in the following
situation:
A DM component C1 that is part of the test remains inactive because it is
awaiting for a service dependency on C2.
But C2 is actually registered in the OSGi service
the threadump did not help.
I will investigate (may be a bug somewhere in my part; if this is the
case, I would be sorry to make all this noise).
hope to let you know soon.
by the way, do you know how to run the SCR integration tests with the
framework from the trunk ? I know that there are
Hi David,
I don't know if it's me (a bug in my benchmark tool) or if if there is a
regression somewhere in the framework, by my parallel test does not pass
anymore.
The test first starts with a single-threaded scenario, which passes OK
I've committed this now in
http://svn.apache.org/viewvc?view=revisionrevision=1679327
Curious to see what others are measuring. My tests were focused on
multiple bundles/threads obtaining the same service, as that's were I
saw a bit of contention.
Cheers,
David
On 13 May 2015 at 15:10, Pierre
Hi David,
I'm looking forward to test your improvements using the dependencymanager
benchmark tool ([1]).
[1]
http://svn.apache.org/viewvc/felix/trunk/dependencymanager/org.apache.felix.dependencymanager.benchmark/
/Pierre
On Wed, May 13, 2015 at 3:02 PM, David Bosschaert
I have implemented the performance improvements that I was thinking of
using Java 5 concurrency tools, they can be viewed at [1].
I wrote a little performance test suite [2] that tests multithreaded
service registry performance (10 threads) from single / multiple
bundles with either singleton
On 3/23/15 10:17 , David Bosschaert wrote:
On 23 March 2015 at 13:39, Richard S. Hall he...@ungoverned.org wrote:
On 3/23/15 03:55 , Guillaume Nodet wrote:
There's a call to interrupt() in Felix#acquireBundleLock(), not sure if it
can be the culprit though.
Interrupts could also be caused by a
On 23 March 2015 at 13:39, Richard S. Hall he...@ungoverned.org wrote:
On 3/23/15 03:55 , Guillaume Nodet wrote:
There's a call to interrupt() in Felix#acquireBundleLock(), not sure if it
can be the culprit though.
Interrupts could also be caused by a bundle being shutdown while one of
its
19 matches
Mail list logo
