Re: Event Admin Java Concurrency Changes

Bob Paulin Thu, 21 Aug 2014 08:17:10 -0700

Hi,

I've got some things in progress but nothing that should hold up therelease. I'm seeing a significant variance in the test results so I'vebeen making some tweaks to the IT that should hopefully smooth that out.Perhaps the most interesting result I'm getting from the tests isthat the postEvent (asynchronous delivery) is taking nearly twice aslong as the sendEvents (synchronous delivery). I would not expect thatmuch difference in performance between the 2 types of submissions.

Below is a typical run. Post event vary by 10+ seconds between runs 40- 50 seconds is the typical range. Send seems a bit more consistentwith runs (22 - 26 seconds)

postEvent
10500000 events in 43635ms

sendEvent
10500000 events in 22914ms

Any thoughts on why this might be?

- Bob
On 8/21/2014 4:49 AM, Carsten Ziegeler wrote:

THanks for your patch Bob, it's applied. The next release of the event
admin will have the version 1.4.0.

I would like to cut a release as soon as possible, or do you think
something needs to changed before?

Carsten


2014-08-18 13:22 GMT+02:00 Carsten Ziegeler <cziege...@apache.org>:

Hi Bob,

I think there is no good reason to keep it separate, I guess I just forgot
to merge them into trunk :)
Therefore, patches welcome :)

Carsten


2014-08-17 20:31 GMT+02:00 Bob Paulin <b...@bobpaulin.com>:

Hi,

Carsten would it make sense to move the IT test from the whiteboard to
the regular code base?  These tests only take about a minute and require a
profile to run anyways so I think include them would be a good idea.  I'd
be happy to integrate the poms to allow this unless there's a reason they
must be separate.  I also have a patch to upgrade it to Pax-Exam 4 which I
had to do for it to work with my OS.

I'll work with those with the TCK for the performance/readability
enhancements but the IT test has been helpful already for some tinkering.
Thanks for the direction!

- Bob


On 8/15/2014 10:40 AM, Carsten Ziegeler wrote:

Hi,


2014-08-15 15:28 GMT+02:00 Jan Willem Janssen <
janwillem.jans...@luminis.eu>
:

  On 15/08/14 14:58, Bob Paulin wrote:

I noticed in https://issues.apache.org/jira/browse/FELIX-3511 Java
Concurrency is being introduced to the code base.  A couple of
thoughts on this.

1) With this not being backwards compatible with earlier versions
does it make sense to increment at least the minor version (ie 1.3
-> 1.4). Java 8 introduces a slew of incompatibility with prior
releases with the changes to the collection libraries so I'm
curious how other projects are handling this.

As I understand the issue, it talks about going from Java 5 to Java 6
as required version, but yes, strictly speaking this would mean a
minor bump at least. We should be more strict on this, I agree (made
the same mistake in the Felix HTTP project as well).

  Actually, as far as I remember the idea was that the version number

reflects the specification version it implements - but this might not
really make sense, so bumping the minor version is a good thing.

  2) Event admin has no tests.  I would be interested in working on

creating some tests for this project.  Any thoughts on where to
begin with this effort?

I think the current implementation is written (and maintained) by
people that have access to the OSGi TCK, so they can tests the
implementation against the specification, which might explain the lack
of unit and integration tests.

  Yepp, the implementation passes the OSGi TCK which I believe tests a

lot of
aspects already.


  But to get started: just start writing unit tests against the code in

trunk and provide them as patches. It is always good to have tests
written by somebody else, as they most often have new/fresh insights
in the use cases...

  Absolutely, we also have some additional tests in the whiteboard area

for
event admin. It's basically a stress test.

  3) It appears there maybe other areas of the event admin code that

might benefit from the Concurrency objects.  Perhaps the use of one
of the Queue constructs for holding some of the asynchronous
events.  Thoughts on this?

As long as it has positive effect on the performance, I think nobody
will complaint about this, if you're willing to provide patches ;)

Right :) This has all been written initially on Java 1.4 so there might
be

areas which can be improved.
However, a nicer implementation is one thing, the other one is
performance.
The goal should be to have a minimum on synchronization between threads
to
get the best performance. I'm not saying the current implementation is
perfect though :)

Carsten


  - --

Met vriendelijke groeten | Kind regards

Jan Willem Janssen | Software Architect
+31 631 765 814

/My world is revolving around INAETICS and Amdatu/

Luminis Technologies B.V.
Churchillplein 1
7314 BZ   Apeldoorn
+31 88 586 46 00

http://www.luminis-technologies.com
http://www.luminis.eu

KvK (CoC) 09 16 28 93
BTW (VAT) NL8169.78.566.B.01
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJT7gruAAoJEKF/mP2eHDc4vO8QANxPmNAzlgzUbhxD0VfLN2++
SlFrTqAGxaIS3rI3fzacBn5Z/v12azwyKLE39WfUEak+i5539LrcQYu8b2mOg4ML
rtz2Yz6r/IcSDixO5y17HrdHyGle58u/gPzJecQqz5j3iqHi4P8eKtNx8FWrG91c
3X56VsP0sb718YswDnu8WXwy8V8I6p1h5vJdYJRx2DcOml+TEcxHxGTH6h7pDePt
DcsPF7E3XaHGWpPvJ5GX8JYjzl80TM5xV4d47VAGdeVCY+JewsC6OlDtxhargGFG
O0wEM9RqI2/R9OTB1K6STIwQZvglyjvUp1odgGEvgl8B/kbSh7WHprtUWIrG+D8Z
cIEBjS9mYIkPEQQo0NMZIqt1XfEMiK5qElqa7v0z8IDGbhaPHy+vGpK84uhItz6M
++tEZ66OGfNaVJG9ueY+093M/J70V57ylw3Mz1Vhf7yChNa1iuT+sCU0OLOPom4K
4UL3H59m9SCXGzg5EoVEglpggdWZCaQ//73mWp7CLob6Kwk8xCvRtC5yVzbxIAgh
UUVcltvSvIDklu9l9k4Di15Q4VyDz9HSu2ZilJJcWln4ZnaanGqxdoRu4tORw7fg
jchVs8Bcw1TmSGTjAwzZkKlFoZfGPPkLpa9/SXYDPfsgeU43hqJyazQ7a7ll0SpP
62oji7tQ0LgRHEnbuZcs
=PraV
-----END PGP SIGNATURE-----


--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

Re: Event Admin Java Concurrency Changes

Reply via email to