Done: https://issues.apache.org/jira/browse/AMQ-6066
If you can incorporate the patch in for 5.13.0 I'd be very grateful.. as it is a pain for us to not use an official release. Also I believe this is a really important performance regression that we'd want to stomp out quickly for ActiveMQ.. Many thanks in advance. Cheers, David On Sat, Nov 28, 2015 at 1:25 AM, Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > Claus is right, open up a Jira and I or someone else can take a look at > this. I don't know if there will be enough time to put this in before > 5.13.0 because I plan on starting the release Monday for that and I'd want > to make sure all the tests run and there would be no unintended issues by > making a change like this. > > However, even if this doesn't go in for 5.13.0, I would expect a bug fix > release (5.13.1) to follow shortly in a month or two and it could be > included in that. It would also be a candidate to be merged into a 5.12.2 > release. > > On Fri, Nov 27, 2015 at 7:40 AM, Claus Ibsen <claus.ib...@gmail.com> > wrote: > > > Hi > > > > Well spotted. I think a good idea is to log a JIRA ticket about this > > so its not forgotten and so the AMQ team can look at it and get it > > into the next release. > > > > On Fri, Nov 27, 2015 at 2:39 AM, David Sitsky <david.sit...@gmail.com> > > wrote: > > > FWIW I changed the contains method as follows: > > > > > > @Override > > > public boolean contains(MessageReference message) { > > > if (message != null) { > > > return map.containsKey(message.getMessageId()); > > > } > > > return false; > > > } > > > > > > I got a speedup for my test taking 29 minutes from 41 minutes. Can we > > get > > > this change in to the upcoming 5.13 release? > > > > > > On Thu, Nov 26, 2015 at 11:44 AM, David Sitsky <david.sit...@gmail.com > > > > > wrote: > > > > > >> Hi, > > >> > > >> I have updated my application from ActiveMQ 5.3 to 5.11.1 and have > > noticed > > >> a performance degregation issue. Running a number of jstacks I can > see > > the > > >> broker is often stuck here: > > >> > > >> "Queue:master-items" Id=122 RUNNABLE > > >> at > > >> > > > org.apache.activemq.broker.region.cursors.OrderedPendingList.contains(OrderedPendingList.java:144) > > >> at > > >> > > > org.apache.activemq.broker.region.Queue.doPageInForDispatch(Queue.java:1930) > > >> at > > org.apache.activemq.broker.region.Queue.pageInMessages(Queue.java:2119) > > >> at org.apache.activemq.broker.region.Queue.iterate(Queue.java:1596) > > >> - locked java.lang.Object@253c3089 > > >> at > > >> > > > org.apache.activemq.thread.DedicatedTaskRunner.runTask(DedicatedTaskRunner.java:112) > > >> at > > >> > > > org.apache.activemq.thread.DedicatedTaskRunner$1.run(DedicatedTaskRunner.java:42) > > >> > > >> Number of locked synchronizers = 1 > > >> - > java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@2eb46567 > > >> > > >> For this specific queue, there are a large number of items in it.. > > around > > >> 100,000. However I noticed the code for contains has: > > >> > > >> public boolean contains(MessageReference message) { > > >> if (message != null) { > > >> for (PendingNode value : map.values()) { > > >> if (value.getMessage().equals(message)) { > > >> return true; > > >> } > > >> } > > >> } > > >> return false; > > >> } > > >> > > >> This will obviously be very slow. Given the Map is keyed by message > ID, > > >> can't we do a .contains(message.getMessageId()) instead? I noticed > the > > >> remove() method does this. I am not familiar with the internals of > > >> ActiveMQ, so I don't know the ramifications of this. > > >> > > >> Cheers, > > >> David > > >> > > > > > > > > -- > > Claus Ibsen > > ----------------- > > http://davsclaus.com @davsclaus > > Camel in Action 2: https://www.manning.com/ibsen2 > > >