Are you turning off blacklisting of event handlers and making sure that all events are actually received by someone as well?
On 21 Aug 2014, at 17:15 pm, Bob Paulin <b...@bobpaulin.com> wrote: > Hi, > > I've got some things in progress but nothing that should hold up the release. > I'm seeing a significant variance in the test results so I've been making > some tweaks to the IT that should hopefully smooth that out. Perhaps the > most interesting result I'm getting from the tests is that the postEvent > (asynchronous delivery) is taking nearly twice as long as the sendEvents > (synchronous delivery). I would not expect that much 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 consistent with 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 >>> >> >> >
