[jira] [Commented] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13914140#comment-13914140 ] Jason Shepherd commented on AMQ-5077: - This issue is also logged in the enterprise 6.1 branch here: https://issues.jboss.org/browse/ENTMQ-569 > Improve performance of ConcurrentStoreAndDispatch > - > > Key: AMQ-5077 > URL: https://issues.apache.org/jira/browse/AMQ-5077 > Project: ActiveMQ > Issue Type: Wish > Components: Message Store >Affects Versions: 5.9.0 > Environment: 5.9.0.redhat-610343 >Reporter: Jason Shepherd >Priority: Minor > Attachments: compDesPerf.tar.gz > > > We have publishers publishing to a topic which has 5 topic -> queue routings, > and gets a max message rate attainable of ~833 messages/sec, with each > message around 5k in size. > To test this i set up a JMS config with topic queues: > Topic > TopicRouted.1 > ... > TopicRouted.11 > Each topic has an increasing number of routings to queues, and a client is > set up to subscribe to all the queues. > Rough message rates: > routings messages/sec > 0 2500 > 1 1428 > 2 2000 > 3 1428 > 4 > 5 833 > This occurs whether the broker config has producerFlowControl="false" set to > true or false , and KahaDB disk synching is turned off. We also tried > experimenting with concurrentStoreAndDispatch, but that didn't seem to help. > LevelDB didn't give any notable performance improvement either. > We also have asyncSend enabled on the producer, and have a requirement to use > persistent messages. We have also experimented with sending messages in a > transaction, but that hasn't really helped. > It seems like producer throughput rate across all queue destinations, all > connections and all publisher machines is limited by something on the broker, > through a mechanism which is not producer flow control. I think the prime > suspect is still contention on the index. > We did some test with Yourkit profiler. > Profiler was attached to broker at startup, allowed to run and then a topic > publisher was started, routing to 5 queues. > Profiler statistics were reset, the publisher allowed to run for 60 seconds, > and then profiling snapshot was taken. During that time, ~9600 messages were > logged as being sent for a rate of ~160/sec. > This ties in roughly with the invocation counts recorded in the snapshot (i > think) - ~43k calls. > From what i can work out, in the snapshot (filtering everything but > org.apache.activemq.store.kahadb), > For the 60 second sample period, > 24.8 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, > MessageAck). > 18.3 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, > Message, boolean). > From these, a further large portion of the time is spent inside > MessageDatabase: > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, > Location) - 10 secs elapsed > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, > Location) - 8.5 secs elapsed. > As both of these lock on indexLock.writeLock(), and both take place on the > NIO transport threads, i think this accounts for at least some of the message > throughput limits. As messages are added and removed from the index one by > one, regardless of sync type settings, this adds a fair amount of overhead. > While we're not synchronising on writes to disk, we are performing work on > the NIO worker thread which can block on locks, and could account for the > behaviour we've seen client side. > To Reproduce: > 1. Install a broker and use the attached configuration. > 2. Use the 5.8.0 example ant script to consume from the queues, > TopicQueueRouted.1 - 5. eg: >ant consumer -Durl=tcp://localhost:61616 -Dsubject=TopicQueueRouted.1 > -Duser=admin -Dpassword=admin -Dmax=-1 > 3. Use the modified version of 5.8.0 example ant script (attached) to send > messages to topics, TopicRouted.1 - 5, eg: >ant producer > -Durl='tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.tightEncodingEnabled=false&keepAlive=true&wireFormat.maxInactivityDuration=6&socketBufferSize=32768' > -Dsubject=TopicRouted.1 -Duser=admin -Dpassword=admin -Dmax=1 -Dtopic=true > -DsleepTime=0 -Dmax=1 -DmessageSize=5000 > This modified version of the script prints the number of messages per second > and prints it to the console. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
[ https://issues.apache.org/jira/browse/AMQ-5077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Shepherd updated AMQ-5077: Attachment: compDesPerf.tar.gz > Improve performance of ConcurrentStoreAndDispatch > - > > Key: AMQ-5077 > URL: https://issues.apache.org/jira/browse/AMQ-5077 > Project: ActiveMQ > Issue Type: Wish > Components: Message Store >Affects Versions: 5.9.0 > Environment: 5.9.0.redhat-610343 >Reporter: Jason Shepherd >Priority: Minor > Attachments: compDesPerf.tar.gz > > > We have publishers publishing to a topic which has 5 topic -> queue routings, > and gets a max message rate attainable of ~833 messages/sec, with each > message around 5k in size. > To test this i set up a JMS config with topic queues: > Topic > TopicRouted.1 > ... > TopicRouted.11 > Each topic has an increasing number of routings to queues, and a client is > set up to subscribe to all the queues. > Rough message rates: > routings messages/sec > 0 2500 > 1 1428 > 2 2000 > 3 1428 > 4 > 5 833 > This occurs whether the broker config has producerFlowControl="false" set to > true or false , and KahaDB disk synching is turned off. We also tried > experimenting with concurrentStoreAndDispatch, but that didn't seem to help. > LevelDB didn't give any notable performance improvement either. > We also have asyncSend enabled on the producer, and have a requirement to use > persistent messages. We have also experimented with sending messages in a > transaction, but that hasn't really helped. > It seems like producer throughput rate across all queue destinations, all > connections and all publisher machines is limited by something on the broker, > through a mechanism which is not producer flow control. I think the prime > suspect is still contention on the index. > We did some test with Yourkit profiler. > Profiler was attached to broker at startup, allowed to run and then a topic > publisher was started, routing to 5 queues. > Profiler statistics were reset, the publisher allowed to run for 60 seconds, > and then profiling snapshot was taken. During that time, ~9600 messages were > logged as being sent for a rate of ~160/sec. > This ties in roughly with the invocation counts recorded in the snapshot (i > think) - ~43k calls. > From what i can work out, in the snapshot (filtering everything but > org.apache.activemq.store.kahadb), > For the 60 second sample period, > 24.8 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, > MessageAck). > 18.3 seconds elapsed in > org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, > Message, boolean). > From these, a further large portion of the time is spent inside > MessageDatabase: > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, > Location) - 10 secs elapsed > org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, > Location) - 8.5 secs elapsed. > As both of these lock on indexLock.writeLock(), and both take place on the > NIO transport threads, i think this accounts for at least some of the message > throughput limits. As messages are added and removed from the index one by > one, regardless of sync type settings, this adds a fair amount of overhead. > While we're not synchronising on writes to disk, we are performing work on > the NIO worker thread which can block on locks, and could account for the > behaviour we've seen client side. > To Reproduce: > 1. Install a broker and use the attached configuration. > 2. Use the 5.8.0 example ant script to consume from the queues, > TopicQueueRouted.1 - 5. eg: >ant consumer -Durl=tcp://localhost:61616 -Dsubject=TopicQueueRouted.1 > -Duser=admin -Dpassword=admin -Dmax=-1 > 3. Use the modified version of 5.8.0 example ant script (attached) to send > messages to topics, TopicRouted.1 - 5, eg: >ant producer > -Durl='tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.tightEncodingEnabled=false&keepAlive=true&wireFormat.maxInactivityDuration=6&socketBufferSize=32768' > -Dsubject=TopicRouted.1 -Duser=admin -Dpassword=admin -Dmax=1 -Dtopic=true > -DsleepTime=0 -Dmax=1 -DmessageSize=5000 > This modified version of the script prints the number of messages per second > and prints it to the console. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5077) Improve performance of ConcurrentStoreAndDispatch
Jason Shepherd created AMQ-5077: --- Summary: Improve performance of ConcurrentStoreAndDispatch Key: AMQ-5077 URL: https://issues.apache.org/jira/browse/AMQ-5077 Project: ActiveMQ Issue Type: Wish Components: Message Store Affects Versions: 5.9.0 Environment: 5.9.0.redhat-610343 Reporter: Jason Shepherd Priority: Minor We have publishers publishing to a topic which has 5 topic -> queue routings, and gets a max message rate attainable of ~833 messages/sec, with each message around 5k in size. To test this i set up a JMS config with topic queues: Topic TopicRouted.1 ... TopicRouted.11 Each topic has an increasing number of routings to queues, and a client is set up to subscribe to all the queues. Rough message rates: routings messages/sec 0 2500 1 1428 2 2000 3 1428 4 5 833 This occurs whether the broker config has producerFlowControl="false" set to true or false , and KahaDB disk synching is turned off. We also tried experimenting with concurrentStoreAndDispatch, but that didn't seem to help. LevelDB didn't give any notable performance improvement either. We also have asyncSend enabled on the producer, and have a requirement to use persistent messages. We have also experimented with sending messages in a transaction, but that hasn't really helped. It seems like producer throughput rate across all queue destinations, all connections and all publisher machines is limited by something on the broker, through a mechanism which is not producer flow control. I think the prime suspect is still contention on the index. We did some test with Yourkit profiler. Profiler was attached to broker at startup, allowed to run and then a topic publisher was started, routing to 5 queues. Profiler statistics were reset, the publisher allowed to run for 60 seconds, and then profiling snapshot was taken. During that time, ~9600 messages were logged as being sent for a rate of ~160/sec. This ties in roughly with the invocation counts recorded in the snapshot (i think) - ~43k calls. >From what i can work out, in the snapshot (filtering everything but >org.apache.activemq.store.kahadb), For the 60 second sample period, 24.8 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.removeAsyncMessage(ConnectionContext, MessageAck). 18.3 seconds elapsed in org.apache.activemq.store.kahadb.KahaDbTransactionStore$1.asyncAddQueueMessage(ConnectionContext, Message, boolean). >From these, a further large portion of the time is spent inside >MessageDatabase: org.apache.activemq.store.kahadb.MessageDatabase.process(KahaRemoveMessageCommand, Location) - 10 secs elapsed org.apache.activemq.store.kahadb.MessageDatabase.process(KahaAddMessageCommand, Location) - 8.5 secs elapsed. As both of these lock on indexLock.writeLock(), and both take place on the NIO transport threads, i think this accounts for at least some of the message throughput limits. As messages are added and removed from the index one by one, regardless of sync type settings, this adds a fair amount of overhead. While we're not synchronising on writes to disk, we are performing work on the NIO worker thread which can block on locks, and could account for the behaviour we've seen client side. To Reproduce: 1. Install a broker and use the attached configuration. 2. Use the 5.8.0 example ant script to consume from the queues, TopicQueueRouted.1 - 5. eg: ant consumer -Durl=tcp://localhost:61616 -Dsubject=TopicQueueRouted.1 -Duser=admin -Dpassword=admin -Dmax=-1 3. Use the modified version of 5.8.0 example ant script (attached) to send messages to topics, TopicRouted.1 - 5, eg: ant producer -Durl='tcp://localhost:61616?jms.useAsyncSend=true&wireFormat.tightEncodingEnabled=false&keepAlive=true&wireFormat.maxInactivityDuration=6&socketBufferSize=32768' -Dsubject=TopicRouted.1 -Duser=admin -Dpassword=admin -Dmax=1 -Dtopic=true -DsleepTime=0 -Dmax=1 -DmessageSize=5000 This modified version of the script prints the number of messages per second and prints it to the console. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (AMQ-5076) Pooled session creation blocks when maxActive is reached
Christian Posta created AMQ-5076: Summary: Pooled session creation blocks when maxActive is reached Key: AMQ-5076 URL: https://issues.apache.org/jira/browse/AMQ-5076 Project: ActiveMQ Issue Type: Improvement Components: activemq-pool Reporter: Christian Posta Pooled session creation blocks when maxActive is reached. This is configurable to either block or thrown an exception. We should maybe expose the config to the generic pool we use under the covers so it can be even more fine tuned, or at least provide a way to set a timeout on the blocking behavior so that threads don't sit and block forever. See http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html and http://commons.apache.org/proper/commons-pool/api-1.6/org/apache/commons/pool/impl/GenericKeyedObjectPool.html#setMaxWait(long) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13913740#comment-13913740 ] Timothy Bish commented on AMQNET-454: - Patches applied. > Add Apache Qpid provider to NMS > --- > > Key: AMQNET-454 > URL: https://issues.apache.org/jira/browse/AMQNET-454 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: NMS >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Jim Gomes > Attachments: Apache.NMS.AMQP-Add-message-cloning-19.patch, > Apache.NMS.AMQP-add-connection-property-table-17.patch, > Apache.NMS.AMQP-add-hello-world-example-11.patch, > Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, > Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, > Apache.NMS.AMQP-add-message-conversions-06.patch, > Apache.NMS.AMQP-add-message-test-20.patch, > Apache.NMS.AMQP-add-topic-05.patch, > Apache.NMS.AMQP-connectionProperties-07.patch, > Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, > Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, > Apache.NMS.AMQP-fix-helloworld-13.patch, > Apache.NMS.AMQP-fix-list-message-body-15.patch, > Apache.NMS.AMQP-fix-map-message-body-14.patch, > Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, > Apache.NMS.AMQP-object-lifecycle-04.patch, > Apache.NMS.AMQP-provider-configs-03.patch, > Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, > Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, > vendor-QPid-nant-01.patch > > > NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This > issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as > another provider. > Qpid has a [Messaging .NET > Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] > that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET > binding is attractive as the hook for tying in Qpid as an NMS provider. > The proposed NMS provider supports [AMQP > 1.0|http://qpid.apache.org/amqp.html] by including [Qpid > Proton|http://qpid.apache.org/proton/index.html] libraries. > From a high level this addition to Active.NMS would consist of two parts > * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid > Proton in a single kit. > * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated AMQNET-454: --- Attachment: Apache.NMS.AMQP-add-message-test-20.patch Patch -20 adds a MessageTest NUnit module to demonstrate various message property manipulations. This patch, developed under VS2008, net-2.0, changes the vs2008 HelloWorld and Test projects to use 'project references' to the Apache.NMS.AMPQ project. Then the dependent projects don't need to have references changes each time the provider is rebuilt. This patch adds a new file which was problematic on some previous commit, so watch for it. > Add Apache Qpid provider to NMS > --- > > Key: AMQNET-454 > URL: https://issues.apache.org/jira/browse/AMQNET-454 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: NMS >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Jim Gomes > Attachments: Apache.NMS.AMQP-Add-message-cloning-19.patch, > Apache.NMS.AMQP-add-connection-property-table-17.patch, > Apache.NMS.AMQP-add-hello-world-example-11.patch, > Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, > Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, > Apache.NMS.AMQP-add-message-conversions-06.patch, > Apache.NMS.AMQP-add-message-test-20.patch, > Apache.NMS.AMQP-add-topic-05.patch, > Apache.NMS.AMQP-connectionProperties-07.patch, > Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, > Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, > Apache.NMS.AMQP-fix-helloworld-13.patch, > Apache.NMS.AMQP-fix-list-message-body-15.patch, > Apache.NMS.AMQP-fix-map-message-body-14.patch, > Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, > Apache.NMS.AMQP-object-lifecycle-04.patch, > Apache.NMS.AMQP-provider-configs-03.patch, > Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, > Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, > vendor-QPid-nant-01.patch > > > NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This > issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as > another provider. > Qpid has a [Messaging .NET > Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] > that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET > binding is attractive as the hook for tying in Qpid as an NMS provider. > The proposed NMS provider supports [AMQP > 1.0|http://qpid.apache.org/amqp.html] by including [Qpid > Proton|http://qpid.apache.org/proton/index.html] libraries. > From a high level this addition to Active.NMS would consist of two parts > * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid > Proton in a single kit. > * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (AMQNET-454) Add Apache Qpid provider to NMS
[ https://issues.apache.org/jira/browse/AMQNET-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke updated AMQNET-454: --- Attachment: Apache.NMS.AMQP-Add-message-cloning-19.patch Patch -19 Add message cloning, base message copy constructor and Equals operator. > Add Apache Qpid provider to NMS > --- > > Key: AMQNET-454 > URL: https://issues.apache.org/jira/browse/AMQNET-454 > Project: ActiveMQ .Net > Issue Type: New Feature > Components: NMS >Affects Versions: 1.6.0 >Reporter: Chuck Rolke >Assignee: Jim Gomes > Attachments: Apache.NMS.AMQP-Add-message-cloning-19.patch, > Apache.NMS.AMQP-add-connection-property-table-17.patch, > Apache.NMS.AMQP-add-hello-world-example-11.patch, > Apache.NMS.AMQP-add-hello-world-example-retry-12.patch, > Apache.NMS.AMQP-add-hello-world-to-vs2008-18.patch, > Apache.NMS.AMQP-add-message-conversions-06.patch, > Apache.NMS.AMQP-add-topic-05.patch, > Apache.NMS.AMQP-connectionProperties-07.patch, > Apache.NMS.AMQP-copyrights-conn-str-fix-09.patch, > Apache.NMS.AMQP-fix-destination-to-use-qpid-address-10.patch, > Apache.NMS.AMQP-fix-helloworld-13.patch, > Apache.NMS.AMQP-fix-list-message-body-15.patch, > Apache.NMS.AMQP-fix-map-message-body-14.patch, > Apache.NMS.AMQP-fix-replyTo-and-receive-timeouts-16.patch, > Apache.NMS.AMQP-object-lifecycle-04.patch, > Apache.NMS.AMQP-provider-configs-03.patch, > Apache.NMS.AMQP-qpid-object-lifecycle-02.patch, > Apache.NMS.AMQP-set-connection-credentials-08.patch, RELEASE.txt, > vendor-QPid-nant-01.patch > > > NMS includes various providers ActiveMQ, STOMP, MSMQ, EMS, and WCF. This > issue proposes to add [Apache Qpid|http://qpid.apache.org/index.html] as > another provider. > Qpid has a [Messaging .NET > Binding|http://qpid.apache.org/releases/qpid-0.24/programming/book/ch05.html] > that is layered on top of the native C++ Qpid Messaging client. The Qpid .NET > binding is attractive as the hook for tying in Qpid as an NMS provider. > The proposed NMS provider supports [AMQP > 1.0|http://qpid.apache.org/amqp.html] by including [Qpid > Proton|http://qpid.apache.org/proton/index.html] libraries. > From a high level this addition to Active.NMS would consist of two parts > * Add Qpid as a vendor kit. This includes both the Qpid .NET Binding and Qpid > Proton in a single kit. > * Add the new provider with code linking NMS to Qpid -- This message was sent by Atlassian JIRA (v6.1.5#6160)
ActiveMQ 5.10 release date?
Now that Camel 2.12.3 has been released (see below) are there any remaining impediments for a timely release of ActiveMQ 5.10? If not, when should its release be expected? Thanks, Paul -- Forwarded message -- From: Willem Jiang Date: Tue, Feb 25, 2014 at 8:56 PM Subject: [ANNOUNCE] Apache Camel 2.12.3 Released To: d...@camel.apache.org, us...@camel.apache.org, annou...@apache.org The Apache Camel project [1] is a powerful open source integration framework based on known Enterprise Integration Patterns [2]. The Camel community announces the immediate availability of the new patch release camel-2.12.3. The artifacts are published and ready for you to download [3] either from the Apache mirrors or from the Central Maven repository. For more details please take a look at the release notes [4]. Many thanks to the Camel community for the hard work. [1] http://camel.apache.org/ [2] http://camel.apache.org/enterprise-integration-patterns.html [3] http://camel.apache.org/download.html [4] http://camel.apache.org/camel-2123-release.html -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem
How to delay consuming messages after connecting to a broker?
I have a trading application which connects a ActiveMQ broker when it starts up, it receives Order/Execution information from that broker, i want to setup a delay so that my trading application can finish the whole startup then it will consume messages from the broker, how can i do that with ActiveMQ API or specify in the broker URL? I'm using Spring JMS + activeMQ 5.6.0. Thanks, J -- View this message in context: http://activemq.2283324.n4.nabble.com/How-to-delay-consuming-messages-after-connecting-to-a-broker-tp4678361.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Commented] (AMQ-1375) ActiveMQ hangs, cannot send message/create temp queue
[
https://issues.apache.org/jira/browse/AMQ-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13912808#comment-13912808
]
Doru Sular commented on AMQ-1375:
-
Hi,
I have the same problem by using java 7, apache-tomcat-7.0.41 and
apache-activemq-5.9.0.
The same code is working well from a unit test,but from tomcat environment
connection.start() never returns, the blocking point is the same reported in
the stacktrace from Dan Tran.
The code sample is here:
{code}
BrokerService broker = new BrokerService();
// configure the broker
try
{
broker.addConnector("tcp://localhost:61616");
broker.start();
broker.waitUntilStarted();
CONNECTION_FACTORY = new
ActiveMQConnectionFactory(broker.getVmConnectorURI());
sendConnection = CONNECTION_FACTORY.createConnection();
sendConnection.start();
}
catch (Exception e)
{
e.printStackTrace();
}
{code}
Everything blocks at *sendConnection.start()*.
Please suggest an workaround or add a fix for that.
Thank you
> ActiveMQ hangs, cannot send message/create temp queue
> -
>
> Key: AMQ-1375
> URL: https://issues.apache.org/jira/browse/AMQ-1375
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.1.1
> Environment: Running an embedded broker in standalone java
> application based on Spring framework on Solaris 10 with JVM version
> 1.5.0_09. Using non persisten messaging with 512MB limit in memory manager of
> broker.
>Reporter: Trevor Higgins
> Fix For: NEEDS_REVIEWED
>
> Attachments: jstack_basic.txt
>
>
> We are experiencing severe issues with AMQ blocking sending. We have a basic
> setup with one standalone server process and many clients. Each client has
> its own temp queue for P2P request/response type communication. There is also
> a number of topics broadcast to all clients. Our clients receive messages in
> an MDP fashion with each message being processed on a single threaded
> executor by an anonymous Runnable as follows:
> {code}
> public void onMessage(final Message message) {
> threadRunner.submit(new Runnable() {
> public void run() {
> try {
> for(final IReceiverListener listener :
> listeners) {
> listener.onReceive(message);
> }
> } catch (Throwable e) {
> e.printStackTrace();
> }
> }
> });
> }
> {code}
> Every so often, the entire AMQ blocks and we cannot send anything anymore. We
> also cannot create any new temp queues, which means no new client can start
> up (each creates its own temp queue during startup). Connections are be
> created and from that a session, but the session.createTemporaryQueue() call
> alwaysy hangs. This is similar to AMQ-1278, but as we are cannot use 5.0
> until stable release...
> Here is the stack of the client trying to create a temp queue
> at Object.wait(long, int) line: not available [native method]
> at CondVar(Object).wait() line: 199
> at CondVar.await() line: 75
> at ArrayBlockingQueue.take() line: 318
> at FutureResponse.getResult() line: 42
> at ResponseCorrelator.request(Object) line: 75
> at ActiveMQConnection.syncSendPacket(Command) line: 1175
> at ActiveMQConnection.createTempDestination(boolean) line: 1594
> at ActiveMQSession.createTemporaryQueue() line: 1134
> at TempDestinationResolver.resolveDestinationName(Session, String, boolean)
> line: 16
> at
> SimpleMessageListenerContainer(JmsDestinationAccessor).resolveDestinationName(Session,
> String) line: 100
> at SimpleMessageListenerContainer.createListenerConsumer(Session) line: 188
> at SimpleMessageListenerContainer.doInitialize() line: 171
> at SimpleMessageListenerContainer(AbstractJmsListeningContainer).initialize()
> line: 160
> at
> SimpleMessageListenerContainer(AbstractJmsListeningContainer).afterPropertiesSet()
> line: 133
> at
> DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).invokeInitMethods(String,
> Object, RootBeanDefinition) line: 1202
> at
> DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).initializeBean(String,
> Object, RootBeanDefinition) line: 1172
> at
> DefaultListableBeanFactory(AbstractAutowireCapableBeanFactory).createBean(String,
> RootBeanDefinition, Object[]) line: 428
> at AbstractBeanFactory$1.getObject() line: 251
> at
> DefaultListableBeanFactory(DefaultSingletonBeanRegistry).getSingleton(String,
> ObjectFactory) line: 156
> at DefaultListableBeanFactory(AbstractBeanFactory).getBean
