[jira] [Updated] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler updated FELIX-4627: Fix Version/s: eventadmin-1.4.2 Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler reassigned FELIX-4627: --- Assignee: Carsten Ziegeler Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Apache Felix Maven plugin
I agree that logically a move of the code base would make sense, however as Stuart points out this comes with some questions around compatibility (maven coordinates, package names). A move would only work, if all these change and we would do kind of a code donation - but then users would have to at least change the group id in their poms. On the other hand, we have some work in the maven plugin which is not directly related to bndtools, so I think there is a need to do a maven bundle plugin release by people from the current group maintaining it from time to time, independent of bnd/bndtoosl releases. I'm not against such a move in general, but we have needs on both sides - so maybe there is some compromise way which makes everyone happy? Regards Carsten 2014-09-02 2:30 GMT+02:00 Stuart McCulloch mccu...@gmail.com: When you say “move … into the bnd build” do you mean check out the source from the Apache SCM and build snapshots as part of bndtools CI, or are you talking about moving/copying code into the bndtools SCM? Also note that while you would be free to do your own releases using a different groupId, anything released under the Apache groupId would need to go through the Apache release process. On 28 Aug 2014, at 15:56, Peter Kriens peter.kri...@aqute.biz wrote: In the bnd(tools) group We currently are discussing the maven bundle plugin. The idea was raised to build this plugin during the normal continuous integration so we can keep the version current. We are already building another maven plugin in our build and releasing it so it should be quite straightforward for us. This would have the benefit that whenever we release a candidate or a final version we would put it in maven central as quickly as possible. From a logical point of view it seems to make sense to move the Apache Felix Bundle plugin into the bnd build since it is so closely coupled to bnd. That said, logical is sometimes to rational (and there might be drawbacks we have not considered). Obviously we do not want to do anything that goes against the wishes of the Apache Felix group, we value this group way too highly to offend it so if the feelings here are not abundantly positive then we won't even look in that direction. Are there any drawbacks? How does this group feel about this? Kind regards, Peter Kriens -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[jira] [Commented] (FELIX-4566) Consistency in PersistenceManager and Cache is not guaranteed
[ https://issues.apache.org/jira/browse/FELIX-4566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118056#comment-14118056 ] Ioannis Canellos commented on FELIX-4566: - Even though getDictionaries() doesn't affect the consistency between cache/file persistance it should still be guarded so that it always returns the snapshot of the cache. Regarding, the eager loading I am not sure. Personally, I think that since the service is backed by files its better to have an error during initialisation than later in the processes. For what it worths, I switched to eager loading so that I can be able to use a lock per pid. But since the getDictionaries() will require a global lock, then yes most probably will can switch back to lazy loading too. Consistency in PersistenceManager and Cache is not guaranteed - Key: FELIX-4566 URL: https://issues.apache.org/jira/browse/FELIX-4566 Project: Felix Issue Type: Bug Components: Configuration Admin Affects Versions: configadmin-1.8.2 Reporter: Ioannis Canellos Assignee: Guillaume Nodet Attachments: FELIX-4566-2.patch, FELIX-4566.patch Currently the store method in the CachingPersistenceManagerProxy performs an update on the PersistenceManager and then also updates the Cache. Since we are updating 2 resources, without any form of synchronisation its possible that the resources are out of sync. For example: Two threads A and B call configuration.update() on the same pid. The first threads calls store(), the PersistenceManager gets updated and then the second thread kicks in updates both PersistenceManager and the cache and finally the first thread updates the cache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4628) [Jetty] Ignore empty string value for truststore
Dominique Pfister created FELIX-4628:
Summary: [Jetty] Ignore empty string value for truststore
Key: FELIX-4628
URL: https://issues.apache.org/jira/browse/FELIX-4628
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.3.0
Reporter: Dominique Pfister
When configuring the Jetty Service through the Web Console, the trust store
defaults to an empty string. If an empty string is passed to jetty's
SslConnector, it interprets it as an empty path, which equals the current
working directory. This results in an exception on startup:
{code}
java.io.FileNotFoundException: /usr/local/apache-felix (No such file or
directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:120)
at
org.eclipse.jetty.util.resource.FileResource.getInputStream(FileResource.java:286)
at
org.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:43)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyStore(SslContextFactory.java:1053)
at
org.eclipse.jetty.util.ssl.SslContextFactory.loadTrustStore(SslContextFactory.java:1027)
at
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:265)
...
{code}
Instead, an empty value for the trust store should be treated as _null_.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Introducing myself :)
Hi everyone! I'm Freddy Guime and wanted to help developing the Apache Felix project. Bob Paulin has been encouraging me to help with the project, and he was telling me this is a great group to join and help. My background is in financial applications (algorithmic trading / high frequency trading software). I also work with Swing, front-end UIs as well. With Bob we run the javapubhouse.com podcast, and have helped write the Java 7/8 Recipes book with Josh Juneau (and co.), and (with Bob) we are the local user group leaders . In all pretty excited to get involved in this apache project. Bob was pointing me to the event admin just to see what could be done in terms of performance/cleaning up so I'm taking a quick peek. Let me know if you have any questions for me. Thanks! Freddy Guime
Re: Introducing myself :)
Welcome to Apache Felix :) If you find any issues please report it on https://issues.apache.org/jira/browse/FELIX and supply patches, also if you have not already, please fill out your ICLA http://www.apache.org/licenses/icla.txt. Cheers, Jamie On Tue, Sep 2, 2014 at 8:22 AM, Freddy Guime fre...@spinningnoodle.com wrote: Hi everyone! I'm Freddy Guime and wanted to help developing the Apache Felix project. Bob Paulin has been encouraging me to help with the project, and he was telling me this is a great group to join and help. My background is in financial applications (algorithmic trading / high frequency trading software). I also work with Swing, front-end UIs as well. With Bob we run the javapubhouse.com podcast, and have helped write the Java 7/8 Recipes book with Josh Juneau (and co.), and (with Bob) we are the local user group leaders . In all pretty excited to get involved in this apache project. Bob was pointing me to the event admin just to see what could be done in terms of performance/cleaning up so I'm taking a quick peek. Let me know if you have any questions for me. Thanks! Freddy Guime
[jira] [Updated] (FELIX-4628) [Jetty] Ignore empty string value for truststore
[
https://issues.apache.org/jira/browse/FELIX-4628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Pfister updated FELIX-4628:
-
Attachment: patch.txt
Trivial patch against trunk to fix issue
[Jetty] Ignore empty string value for truststore
Key: FELIX-4628
URL: https://issues.apache.org/jira/browse/FELIX-4628
Project: Felix
Issue Type: Bug
Components: HTTP Service
Affects Versions: http-2.3.0
Reporter: Dominique Pfister
Attachments: patch.txt
When configuring the Jetty Service through the Web Console, the trust store
defaults to an empty string. If an empty string is passed to jetty's
SslConnector, it interprets it as an empty path, which equals the current
working directory. This results in an exception on startup:
{code}
java.io.FileNotFoundException: /usr/local/apache-felix (No such file or
directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.init(FileInputStream.java:120)
at
org.eclipse.jetty.util.resource.FileResource.getInputStream(FileResource.java:286)
at
org.eclipse.jetty.util.security.CertificateUtils.getKeyStore(CertificateUtils.java:43)
at
org.eclipse.jetty.util.ssl.SslContextFactory.getKeyStore(SslContextFactory.java:1053)
at
org.eclipse.jetty.util.ssl.SslContextFactory.loadTrustStore(SslContextFactory.java:1027)
at
org.eclipse.jetty.util.ssl.SslContextFactory.doStart(SslContextFactory.java:265)
...
{code}
Instead, an empty value for the trust store should be treated as _null_.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4627. - Resolution: Fixed Thanks for your patch, Bob - I've applied a slightly modified version which adds the executor to the map when it gets reactivated. Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Paulin updated FELIX-4627: -- Attachment: FELIX-4627b.patch Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch, FELIX-4627b.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118229#comment-14118229 ] Bob Paulin commented on FELIX-4627: --- Thanks for catching that use case. Since there's no locking on the null check this makes sense. With that addition I think we can remove the put that's outside of the synchronized block. This will prevent an additional put that occurs when the remove is executed before the next send request checks the running threads map for null (outside the synchronized block). I've attached another patch. Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch, FELIX-4627b.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bob Paulin reopened FELIX-4627: --- Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch, FELIX-4627b.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-4609) Possible ConcurrentModificationException in WatcherScanner
[
https://issues.apache.org/jira/browse/FELIX-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118233#comment-14118233
]
Andre Flakowski edited comment on FELIX-4609 at 9/2/14 2:30 PM:
I reproduced the problem under Karaf 2.3.6 as well.
I traced it back to the same Issue: The problem is the removal of a config file
in line 83 (changed.remove(file)) which causes the HashMap to throw the
ConcurrentModificationException.
was (Author: apf):
I reproduced the problem under Karaf 2.3.6 as well.
I traced it back to the same Issue: The problem is the removal of a config file
in line 83 (changed.remove(file);) which causes the HashMap to throw the
ConcurrentModificationException.
Possible ConcurrentModificationException in WatcherScanner
--
Key: FELIX-4609
URL: https://issues.apache.org/jira/browse/FELIX-4609
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.4.0
Reporter: Daniel Kulp
In some cases at startup, I'm getting:
{code}
12:02:06,941 | ERROR | OT/container/etc | ?
? | 6 - org.apache.felix.fileinstall - 3.4.0 | In main loop, we have serious
trouble
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)[:1.7.0_67]
at java.util.HashMap$KeyIterator.next(HashMap.java:956)[:1.7.0_67]
at
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:70)[6:org.apache.felix.fileinstall:3.4.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:305)[6:org.apache.felix.fileinstall:3.4.0]
{code}
The problem looks to stem from line 83 of WatcherScanner. The changed
HashSet is being modified (remove call) within the for loop that is iterating
over it.
Most likely, a small change of:
{code}
Index: WatcherScanner.java
===
--- WatcherScanner.java (revision 1619096)
+++ WatcherScanner.java (working copy)
@@ -78,10 +78,8 @@
if ((newChecksum == lastChecksum || reportImmediately)) {
if (newChecksum != storedChecksum) {
storedChecksums.put(file, newChecksum);
-files.add(file);
-} else {
-changed.remove(file);
}
+files.add(file);
if (reportImmediately) {
removed.remove(file);
}
{code}
will fix it, but untested at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4609) Possible ConcurrentModificationException in WatcherScanner
[
https://issues.apache.org/jira/browse/FELIX-4609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14118233#comment-14118233
]
Andre Flakowski commented on FELIX-4609:
I reproduced the problem under Karaf 2.3.6 as well.
I traced it back to the same Issue: The problem is the removal of a config file
in line 83 (changed.remove(file);) which causes the HashMap to throw the
ConcurrentModificationException.
Possible ConcurrentModificationException in WatcherScanner
--
Key: FELIX-4609
URL: https://issues.apache.org/jira/browse/FELIX-4609
Project: Felix
Issue Type: Bug
Components: File Install
Affects Versions: fileinstall-3.4.0
Reporter: Daniel Kulp
In some cases at startup, I'm getting:
{code}
12:02:06,941 | ERROR | OT/container/etc | ?
? | 6 - org.apache.felix.fileinstall - 3.4.0 | In main loop, we have serious
trouble
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922)[:1.7.0_67]
at java.util.HashMap$KeyIterator.next(HashMap.java:956)[:1.7.0_67]
at
org.apache.felix.fileinstall.internal.WatcherScanner.scan(WatcherScanner.java:70)[6:org.apache.felix.fileinstall:3.4.0]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:305)[6:org.apache.felix.fileinstall:3.4.0]
{code}
The problem looks to stem from line 83 of WatcherScanner. The changed
HashSet is being modified (remove call) within the for loop that is iterating
over it.
Most likely, a small change of:
{code}
Index: WatcherScanner.java
===
--- WatcherScanner.java (revision 1619096)
+++ WatcherScanner.java (working copy)
@@ -78,10 +78,8 @@
if ((newChecksum == lastChecksum || reportImmediately)) {
if (newChecksum != storedChecksum) {
storedChecksums.put(file, newChecksum);
-files.add(file);
-} else {
-changed.remove(file);
}
+files.add(file);
if (reportImmediately) {
removed.remove(file);
}
{code}
will fix it, but untested at this point.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (FELIX-4627) Event Admin - Memory Leak in AsyncDeliverTasks
[ https://issues.apache.org/jira/browse/FELIX-4627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carsten Ziegeler resolved FELIX-4627. - Resolution: Fixed Good point, it's gone now. Thanks! Event Admin - Memory Leak in AsyncDeliverTasks -- Key: FELIX-4627 URL: https://issues.apache.org/jira/browse/FELIX-4627 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0 Reporter: Bob Paulin Assignee: Carsten Ziegeler Priority: Minor Fix For: eventadmin-1.4.2 Attachments: FELIX-4627.patch, FELIX-4627b.patch Currently the AsyncDeliverTasks has a Map that tracks running threads (essentially a ThreadLocal like implementation). As new threads post async events this list will continue to grow and is never cleared out. Over time this will create a slow memory leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4629) Event Admin Documentation - Properties and Property Defaults Incorrect
Bob Paulin created FELIX-4629: - Summary: Event Admin Documentation - Properties and Property Defaults Incorrect Key: FELIX-4629 URL: https://issues.apache.org/jira/browse/FELIX-4629 Project: Felix Issue Type: Bug Components: Event Admin Affects Versions: eventadmin-1.4.0, eventadmin-1.3.0 Reporter: Bob Paulin Priority: Minor The documentation at http://felix.apache.org/site/apache-felix-event-admin.html appears to be out of date with the current release. 1) There is no CacheSize Property 2) ThreadPoolSize defaults to 20 3) No mention of IgnoreTopic and LogLevel -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-4630) Adding PerformanceTestIT to measure difference between send and post events
Freddy Guime created FELIX-4630: --- Summary: Adding PerformanceTestIT to measure difference between send and post events Key: FELIX-4630 URL: https://issues.apache.org/jira/browse/FELIX-4630 Project: Felix Issue Type: Test Components: Event Admin Affects Versions: eventadmin-1.4.2 Reporter: Freddy Guime Priority: Minor This is an integration test that attempts to measure performance when sending messages using send and post. The test cycles through a warmup phase and tries to then create a work queue. The listeners then use a countdownlatch to minimize synchronization contention in the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4630) Adding PerformanceTestIT to measure difference between send and post events
[ https://issues.apache.org/jira/browse/FELIX-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freddy Guime updated FELIX-4630: Attachment: performanceTestIT.patch First patch Adding PerformanceTestIT to measure difference between send and post events --- Key: FELIX-4630 URL: https://issues.apache.org/jira/browse/FELIX-4630 Project: Felix Issue Type: Test Components: Event Admin Affects Versions: eventadmin-1.4.2 Reporter: Freddy Guime Priority: Minor This is an integration test that attempts to measure performance when sending messages using send and post. The test cycles through a warmup phase and tries to then create a work queue. The listeners then use a countdownlatch to minimize synchronization contention in the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4630) Adding PerformanceTestIT to measure difference between send and post events
[ https://issues.apache.org/jira/browse/FELIX-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freddy Guime updated FELIX-4630: Attachment: (was: performanceTestIT.patch) Adding PerformanceTestIT to measure difference between send and post events --- Key: FELIX-4630 URL: https://issues.apache.org/jira/browse/FELIX-4630 Project: Felix Issue Type: Test Components: Event Admin Affects Versions: eventadmin-1.4.2 Reporter: Freddy Guime Priority: Minor This is an integration test that attempts to measure performance when sending messages using send and post. The test cycles through a warmup phase and tries to then create a work queue. The listeners then use a countdownlatch to minimize synchronization contention in the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-4630) Adding PerformanceTestIT to measure difference between send and post events
[ https://issues.apache.org/jira/browse/FELIX-4630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Freddy Guime updated FELIX-4630: Attachment: FELIX-4630.patch Adding PerformanceTestIT to measure difference between send and post events --- Key: FELIX-4630 URL: https://issues.apache.org/jira/browse/FELIX-4630 Project: Felix Issue Type: Test Components: Event Admin Affects Versions: eventadmin-1.4.2 Reporter: Freddy Guime Priority: Minor Attachments: FELIX-4630.patch This is an integration test that attempts to measure performance when sending messages using send and post. The test cycles through a warmup phase and tries to then create a work queue. The listeners then use a countdownlatch to minimize synchronization contention in the test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
