Thanks rajdavies for the quick response. it will be difficult or time-consuming to create a junit test case, as the application is complex and uses UCP as the receiving interface.
Maybe i can give more info on the problem encountered here. We found out the threads in our application were stuck with the following error through JConsole when we used activemq 4.1.2. Name: ClearTextSMSUCPAdp02-UcpAdapterUcpTextHandler_015 State: WAITING on edu.emory.mathcs.backport.java.util.concurrent.locks.cond...@445e0acb Total blocked: 33,632 Total waited: 24,745 Stack trace: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:485) edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar.await(CondVar.java:76) edu.emory.mathcs.backport.java.util.concurrent.ArrayBlockingQueue.take(ArrayBlockingQueue.java:319) org.apache.activemq.transport.FutureResponse.getResult(FutureResponse.java:42) org.apache.activemq.transport.ResponseCorrelator.request(ResponseCorrelator.java:75) org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1175) org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:1663) org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsumer.java:542) The search result from the web suggests it's fixed at a higher version of activemq, and hence we decided to give the latest version a try, but found out our application slowed down. I also tried using a lower version, activemq 5.1.0. The application failed within seconds and we are yet to identify the root cause. If it's hard to investigate the difference, can we solve the locking issue by applying some patches to activemq 4.1.2 copy instead? Or is there any better suggestion? rajdavies wrote: > > There's been a lot of changes - if you could provide a junit test case > that is representative of your application - that would enable us to > investigate the difference > > On 7 Feb 2010, at 07:36, hwl wrote: > >> >> Our application previously ran on activemq 4.1.2 and was able to >> achieve < >> 500ms response time in average. However, some locking issue was >> observed >> (WAITING on >> edu.emory.mathcs.backport.java.util.concurrent.locks.CondVar) >> and we upgraded the activemq component to 5.3.0. The locking issue >> does not >> occur so far, but the performance drops to >2 second on average >> response >> time which breaches the performance critieria. >> >> Any idea what could introduce such significant overhead and any way >> to tune >> it? >> >> Our messaging service is non-persistent and activemq has been >> configured >> accordingly. >> >> thanks! >> >> - Wanling >> -- >> View this message in context: >> http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27486527.html >> Sent from the ActiveMQ - User mailing list archive at Nabble.com. >> > > Rob Davies > http://twitter.com/rajdavies > I work here: http://fusesource.com > My Blog: http://rajdavies.blogspot.com/ > I'm writing this: http://www.manning.com/snyder/ > > > > > > > -- View this message in context: http://old.nabble.com/activemq-5.3-slower-than-4.1.2--tp27486527p27494788.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
