You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Bob Paulin <bo...@bobpaulin.com> on 2014/08/15 14:58:58 UTC
Event Admin Java Concurrency Changes
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.
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?
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?
- Bob
Re: Event Admin Java Concurrency Changes
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <bo...@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 <bo...@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 <cz...@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 <bo...@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.janssen@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
>>>>> cziegeler@apache.org
>>>>>
>>>>>
>>>>
>>
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Event Admin Java Concurrency Changes
Posted by Bob Paulin <bo...@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 <bo...@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 <cz...@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 <bo...@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.janssen@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
>>>> cziegeler@apache.org
>>>>
>>>
>
Re: Event Admin Java Concurrency Changes
Posted by Marcel Offermans <ma...@luminis.eu>.
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 <bo...@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 <cz...@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 <bo...@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.janssen@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
>>> cziegeler@apache.org
>>>
>>
>>
>
Re: Event Admin Java Concurrency Changes
Posted by Bob Paulin <bo...@bobpaulin.com>.
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 <cz...@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 <bo...@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.janssen@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
>> cziegeler@apache.org
>>
>
>
Re: Event Admin Java Concurrency Changes
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <cz...@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 <bo...@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.janssen@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
> cziegeler@apache.org
>
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: Event Admin Java Concurrency Changes
Posted by Carsten Ziegeler <cz...@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 <bo...@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.janssen@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
cziegeler@apache.org
Re: Event Admin Java Concurrency Changes
Posted by Bob Paulin <bo...@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 <ja...@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-----
>>
>
>
Re: Event Admin Java Concurrency Changes
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi,
2014-08-15 15:28 GMT+02:00 Jan Willem Janssen <ja...@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
cziegeler@apache.org
Re: Event Admin Java Concurrency Changes
Posted by Jan Willem Janssen <ja...@luminis.eu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Bob,
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).
> 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.
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...
> 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 ;)
- --
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-----