Hi, thanks Bob, I'll cut a release then now - if we improve things we can simply cut a new one afterwards.
Now, if blacklisting is used (the default), synchronous event sending is done in a separate thread. For asynchronous sending there are two threads involved, the first one acting like kind of a queue and once an event is fetched from the queue, the code from the async sending is used. And I guess that explains the difference in performance. Regards Carsten 2014-08-22 2:53 GMT+02:00 Bob Paulin <b...@bobpaulin.com>: > The test harness sets up several event handlers which receive the events > and update the count of events received. The timing is stopped when the > count of events received is equal to the number of events sent. The code > does not set a timeout for the event admin and I'm not seeing any handlers > getting blacklisted in the logs. The code for the test harness is at > > http://svn.apache.org/viewvc/felix/trunk/eventadmin/impl/ > src/test/java/org/apache/felix/eventadmin/ittests/ > > The send event can be flipped from synchronous to asynchronous by flipping > the boolean in the StressTestIT.java. The events are still being processed > very fast but it would be nice if the difference could be explained. > > protected void sendEvent(int index) { > final String postFix = String.valueOf(index % 10); > final String topic = PREFIX + '/' + postFix; > this.send(topic, null, *true*); > } > > - Bob > > > On 8/21/2014 3:47 PM, Marcel Offermans wrote: > >> 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 >>>>> >>>>> >>>> >> > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
