Stop sending messages to broker
Hi, In my scenario I have one boroker, one producer, one consumer.I am using activemq for writing my app. logs to db.As u know writing logs to db is time taking process.That's why consumer is more and more slow than producer.For ex. I send 100.000 message(huge objects).Producer finishes sending messages in 20 mins.But When the producer finished, consumer has finished 4.000 message processing yet. My question is ; is there any way to say procuder wait if there are x messages in the broker waiting for consuming and try to send after a while how can solve this problem. -- View this message in context: http://activemq.2283324.n4.nabble.com/Stop-sending-messages-to-broker-tp4671596.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
Stop sending messages to broker
Hi, In my scenario I have one boroker, one producer, one consumer.I am using activemq for writing my app. logs to db.As u know writing logs to db is time taking process.That's why consumer is more and more slow than producer.For ex. I send 100.000 message(huge objects).Producer finishes sending messages in 20 mins.But When the producer finished, consumer has finished 4.000 message processing yet. My question is ; is there any way to say procuder wait if there are x messages in the broker waiting for consuming and try to send after a while how can solve this problem. -- View this message in context: http://activemq.2283324.n4.nabble.com/Stop-sending-messages-to-broker-tp4671595.html Sent from the ActiveMQ - Dev mailing list archive at Nabble.com.
[jira] [Commented] (AMQ-4701) NIO transport performance for ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770637#comment-13770637 ] Anuj Khandelwal commented on AMQ-4701: -- Hi Timothy, I have also tested NIO transport with large number of clients, please find below details for test performance results: USING 20 producers ClientsNo. of threads before running producer No. of threads after running producers(~20) STOMP (PYTHON producer) 63 72 STOMP +NIO(PYTHON producer) 67 82 TCP(JAVA producer)58 86 NIO(JAVA producer)58 87 Transport Connector in broker configuration is : amq:transportConnectors amq:transportConnector name=amqBrokerTcpTransport uri=tcp://0.0.0.0:61616 / amq:transportConnector name=amqBrokerNioTransport uri=nio://0.0.0.0:61615 / amq:transportConnector name=amqBrokerStompTransport uri=stomp://0.0.0.0:61613 / amq:transportConnector name=amqBrokerStompNioTransport uri=stomp+nio://0.0.0.0:61614 / /amq:transportConnectors Thanks, Anuj NIO transport performance for ActiveMQ -- Key: AMQ-4701 URL: https://issues.apache.org/jira/browse/AMQ-4701 Project: ActiveMQ Issue Type: Test Components: Performance Test, Transport Affects Versions: 5.8.0 Reporter: Anuj Khandelwal Hi, I am using 5.8.0 version of ActiveMQ. I am trying to use NIO to improve performance and scalability of my ActiveMQ broker but it is not working well. I was expecting that it should reduce number of threads but I have not observed any changes in number of threads. It is even reducing the throughput. I have made changes in broker's configuration file as specified http://activemq.apache.org/configuring-transports.html Can somebody help me here. Thanks, Anuj -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4701) NIO transport performance for ActiveMQ
[ https://issues.apache.org/jira/browse/AMQ-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770639#comment-13770639 ] Anuj Khandelwal commented on AMQ-4701: -- Bad formatting for performance results in above post. Tests are carried out with 20 producers. Please find below details: STOMP (PYTHON producer) 63(before running producers) 72(after running producers) STOMP +NIO(PYTHON producer) 67(before running producers) 82(after running producers) TCP(JAVA producer) 58(before running producers) 86(after running producers) NIO(JAVA producer) 58(before running producers) 87(after running producers) Thanks, Anuj NIO transport performance for ActiveMQ -- Key: AMQ-4701 URL: https://issues.apache.org/jira/browse/AMQ-4701 Project: ActiveMQ Issue Type: Test Components: Performance Test, Transport Affects Versions: 5.8.0 Reporter: Anuj Khandelwal Hi, I am using 5.8.0 version of ActiveMQ. I am trying to use NIO to improve performance and scalability of my ActiveMQ broker but it is not working well. I was expecting that it should reduce number of threads but I have not observed any changes in number of threads. It is even reducing the throughput. I have made changes in broker's configuration file as specified http://activemq.apache.org/configuring-transports.html Can somebody help me here. Thanks, Anuj -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4721) Update slf4j library to latest version (1.7.5 currently)
[ https://issues.apache.org/jira/browse/AMQ-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770675#comment-13770675 ] Jean-Baptiste Onofré commented on AMQ-4721: --- I gonna provide a more global patch covering all ActiveMQ modules. Thanks a lot Timothy for your review ! Update slf4j library to latest version (1.7.5 currently) Key: AMQ-4721 URL: https://issues.apache.org/jira/browse/AMQ-4721 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.8.0 Reporter: Timothy Bish Assignee: Jean-Baptiste Onofré Priority: Minor Fix For: 5.9.0 Attachments: AMQ-4721.patch We are currently on an older release v1.6.6 and should move on to the latest v1.7.5 to pick up performance improvements etc. From the changelog: performance improvements: The logger factories in most SLF4J modules namely in jcl-over-slf4j, log4j-over-slf4j, slf4j-jcl, slf4j-jdk14, slf4j-log4j12, and slf4j-simple now use a ConcurrentHashMap instead of a regular HashMap to cache logger instances. This change significantly improves logger retrieval times at the cost of some memory overhead. This improvement was requested in bug #298 by Taras Tielkes who also provided the relevant patch. Given the significance of these performance improvements, users are highly encouraged to migrate to SLF4J version 1.7.5 or later. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish reopened AMQ-4718: --- These changes seems to have broken the FailoverUriTest as its not detecting bad options Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs. Key: AMQ-4718 URL: https://issues.apache.org/jira/browse/AMQ-4718 Project: ActiveMQ Issue Type: New Feature Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.9.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770812#comment-13770812 ] Hiram Chirino commented on AMQ-4718: documented on the wiki. Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs. Key: AMQ-4718 URL: https://issues.apache.org/jira/browse/AMQ-4718 Project: ActiveMQ Issue Type: New Feature Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.9.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4725) FailoverUriTest hangs
[
https://issues.apache.org/jira/browse/AMQ-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-4725.
---
Resolution: Fixed
Fixed now, tests restored
FailoverUriTest hangs
--
Key: AMQ-4725
URL: https://issues.apache.org/jira/browse/AMQ-4725
Project: ActiveMQ
Issue Type: Bug
Components: Test Cases
Reporter: Kevin Earls
Attachments: AMQ-4725.patch, AMQ-4725stack.txt
The TestBadVersionNumberDoesNotWork and TestBadPropertyNameFails both hang
when the init method adds the following:
addCombinationValues(postfix, new Object[]
{)?initialReconnectDelay=1000maxReconnectDelay=1000});
I'll attach a patch which comments these out so the build doesn't hang, as
well as a stack trace.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (AMQ-4718) Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs.
[ https://issues.apache.org/jira/browse/AMQ-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770812#comment-13770812 ] Hiram Chirino edited comment on AMQ-4718 at 9/18/13 2:27 PM: - documented on the wiki: https://cwiki.apache.org/confluence/display/ACTIVEMQ/Failover+Transport+Reference#FailoverTransportReference-PassingextraoptionstothenestedURLs. was (Author: chirino): documented on the wiki. Extra options added to a failover/discovery URL that don't map to failover configuration settings, should get passed to the nested URLs. Key: AMQ-4718 URL: https://issues.apache.org/jira/browse/AMQ-4718 Project: ActiveMQ Issue Type: New Feature Components: JMS client Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 5.9.0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Bosanac updated AMQ-4533: --- Attachment: AMQFreezeTest.zip It still unusual to me to call all these interrupts, as I cannot image a scenario in real life that will do the similar thing to the application. Anyhow, I did some changes to the configuration of thins I have a test that now passes all the time for me (please find it attached). Things that are changed: - one of the most important things is to move spring consumer to client acknowlegdment (look listener.xml). The spring container will synchronosuly receive messages and pass them to listener. So in case of the long running listener, the message is acked imidiatelly, which causes problems later. - conditionalNetworkBridgeFilterFactory policy and larger ttl, as consumers can come and go to different brokers and we need to be able to pass messages back and forth - ignoreIdleConsumers=true as we don't want to kill connections of idle consumers - abortConnection=false as we don't want to kill the connection just a misbehaving consumer Can you guys run this version of the test and see how it works for you? Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wieslaw Dudek updated AMQ-4533: --- Attachment: AMQFreezeTest-5.9.0.redhat-610084-log.zip Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wieslaw Dudek updated AMQ-4533: --- Attachment: AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip For me the last AMQFreezeTest.zip is still failing both using the 5.8 snapshot containing the slow abort consumer strategy and latest 5.9 binaries. Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770952#comment-13770952 ] Timothy Bish commented on AMQ-4533: --- Idle consumers are consumers that have no outstanding dispatched messages. These consumer have nothing to do and therefore would always trip the slow condition and eventually be closed. In the case of having the abortConnection=true this means that you'd have consumer connection coming and going for no real reason which could impact performance of your application. I don't see why you'd want to not just ignore the idle one's and only focus on consumers that have not ack'd outstanding messages in the allocated time. Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770941#comment-13770941 ] Wieslaw Dudek commented on AMQ-4533: Please advise why do you think the auto_acknowledge option should not be used? I managed to get the both test cases to pass using the ignoreIdleConsumers=false and abortConnection=true if we consider the traces only /the messages really received/ and not taking into account the wrong statistics. I got all the messages consumed by the spring consumers. The slow strategy after being triggered a few times was able to close the connections and they have been recreated by spring consumers only so I had to modify the test cases to use the spring configuration for both INPUT_QUEUE RECEIPT_QUEUE. I used the original test cases in form I sent here with the mentioned modifications. What might be the risk for us to use the ignoreIdleConsumers=false and abortConnection=true? Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4594) Replace web console with hawtio
[ https://issues.apache.org/jira/browse/AMQ-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770989#comment-13770989 ] Miquel Angel Escolar commented on AMQ-4594: --- I just installed the latest activemq snapshot (apache-activemq-5.9-20130905.132141-99-bin) from repo and when i execute activemq, i get the above exception logged by Timothy. Any ideas? Replace web console with hawtio --- Key: AMQ-4594 URL: https://issues.apache.org/jira/browse/AMQ-4594 Project: ActiveMQ Issue Type: New Feature Affects Versions: 5.8.0 Reporter: Dejan Bosanac Assignee: Dejan Bosanac Fix For: 5.9.0 Our administration web console has come to age and we should replace with hawtio (http://hawt.io) project. Of course, we should make sure that ActiveMQ plugin is feature compatible with current console. hawtio provides lots of extra capabilities over the old web console; we can send messages, move messages, delete messages and easily replay DLQ messages; together with visualising producer/consumer flows and providing real time metrics and charting on destinations. Plus hawtio is much smaller than the old web console; we can also use the hawtio console remotely to connect to other brokers and JVMs which just contain the tiny jolokia java agent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (AMQ-4726) Text information of ant producer durable option is not correct
[
https://issues.apache.org/jira/browse/AMQ-4726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish resolved AMQ-4726.
---
Resolution: Fixed
Fix Version/s: 5.9.0
Updated the verbiage to be clear what this options means to producers. Didn't
change the option name so as not to break current users.
Text information of ant producer durable option is not correct
--
Key: AMQ-4726
URL: https://issues.apache.org/jira/browse/AMQ-4726
Project: ActiveMQ
Issue Type: Bug
Reporter: Charles Moulliard
Fix For: 5.9.0
The ant build.xml file of activemq reports that durable option will create
a durable subscriber
{code}
[echo] ant producer options - Creates a producer
publishing a number of messages
[echo]
[echo] Producer Options:
[echo] url - Used to specify acustom URL for
the broker,
[echo] e.g., tcp://hostname:1234
[echo] topic - A boolean to determine whether
to use topics
[echo] or queues
[echo] subject - Used to specify a custom
destination name,
[echo] e.g. MyDestination
[echo] durable - A boolean to specify that you
want to create
[echo] a durable topic subscriber?
{code}
Obviously, this is a mistake as the durable option for the producer allows
to change DeliveryMode of the message ('PERSISTENT' or 'NON-PERSISTENT')
Maybe, we should use 'persistent' as property name but then the build.xml
file and java class need to be changed
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-4624) Support Time To Live for activemq connection that uses tcp and nio transport
[ https://issues.apache.org/jira/browse/AMQ-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4624. - Resolution: Won't Fix Fix Version/s: (was: NEEDS_REVIEWED) You can use the new AbortSlowAckConsumerPolicy to boot idle consumers that match certain criteria. Support Time To Live for activemq connection that uses tcp and nio transport Key: AMQ-4624 URL: https://issues.apache.org/jira/browse/AMQ-4624 Project: ActiveMQ Issue Type: New Feature Components: Transport Affects Versions: 5.9.0 Reporter: Hazem Mashlah Priority: Minor Attachments: transport_ttl.diff Add a new connection string parameter to support a time to live (expiry time) for activemq connection -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-4174) Deleting/moving a message from queue overview should redirect back to overview of the queue
[ https://issues.apache.org/jira/browse/AMQ-4174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4174. - Resolution: Won't Fix Web console is to be replaced by HawtIO in the next release. Deleting/moving a message from queue overview should redirect back to overview of the queue --- Key: AMQ-4174 URL: https://issues.apache.org/jira/browse/AMQ-4174 Project: ActiveMQ Issue Type: Improvement Affects Versions: 5.7.0 Reporter: Torbjørn Skyberg Knutsen Priority: Minor Attachments: AMQ4174.patch When one deletes a message from the overview of a queue, one is redirected to the overview showing all queues. This makes deleting multiple messages tedious work, since you have to find the queue to delete from for each message that you want to delete. The same goes for moving a message, you get thrown back to start instead of the queue overview, which would be nice in cases where you want to move multiple messages in the same queue (which is quite often, specially for dead-letter queues). Is it possible to change the redirect to the overview of the queue that was moved/deleted from? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (AMQ-4136) Broker freezes on peak burst producer persistent message delivery
[ https://issues.apache.org/jira/browse/AMQ-4136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4136. - Resolution: Cannot Reproduce Broker freezes on peak burst producer persistent message delivery - Key: AMQ-4136 URL: https://issues.apache.org/jira/browse/AMQ-4136 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.6.0 Environment: Java 1.6.0_35 Mac OSX 10.7.5 Reporter: David Israel Priority: Critical Attachments: activemq.xml Expected: throttled messages when tempStorage reaches 100% Actual: broker hangs and no longer delivers messages and cannot be cleanly shutdown Configuration: - /conf/activemq.xml (attached) configuration: memoryUsage: 200MB, storeUsage: 1GB, tempUsage: 400MB - test configuration (/example/build.xml): max (# of messages): 65000, messageSize: 1 - total message size: 65000 * 1 bytes = 650 MB Result: - burst of 65000 messages to queue, initially loads into memory but quickly gets dumped to tempStorage (12% memoryUsage) - messages persisted in database - producer throttling does NOT occur, potentially b/c memoryUsage is at 0% in this peak/burst scenario when activmq stops responding - activemq process hangs at 104% tempUsage, 0% memoryUsage, and can't be shutdown without force kill commands from standard release examples: Start amq: /bin$ ./activemq console start producer: ant producer -Ddurable=true -DsleepTime=0 (Bug experienced with higher sleep times also.) if you want to use consumers: ant consumer -Durl=tcp://localhost:61616?jms.prefetchPolicy.queuePrefetch=1 - watch memory and disk usage in jconsole http://tmielke.blogspot.com/2011/02/observations-on-activemqs-temp-storage.html workarounds: 1) no tempUsage storage at all \conf\activemq.xml - tempUsage limit=0 mb/ 2) try to hide tempUsage \conf\activemq.xml - tempUsage limit=4 gb/ - 4 gb being much, much larger than uninterrupted usage will fill -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (AMQ-2453) start/control-script is not suitable for professional environments
[ https://issues.apache.org/jira/browse/AMQ-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish updated AMQ-2453: -- Fix Version/s: (was: 5.7.0) NEEDS_REVIEWED start/control-script is not suitable for professional environments -- Key: AMQ-2453 URL: https://issues.apache.org/jira/browse/AMQ-2453 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.3.0 Reporter: Marc Schöchlin Assignee: Timothy Bish Fix For: NEEDS_REVIEWED Attachments: activemq, usage-example.txt The start-scripts activemq and activemq-admin do not seem to be ready for production use. Reasons: - Server does not run in background = this can be done by redirecting output to a file and run in background = in my opinion this should be implemented directly in java = the console log should be written by log4j to install-root/data/console.log - The process should be started on a non-root user = use 'su -c $COMMAND - $RUN_AS_USER' = this should be defined in /etc/activemq.conf - The script should support a reload feature to reload the configurartion (if activemq supports reloading) - The script should support a status option = this should show a quick overview about the state of activemq = this should return a value != 0 if the service is not working (this is important for cluster integration) Does anybody already working on these items? Do you have suggestions for a implementation? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (AMQ-4533) Messages stuck in queue with redelivered=true
[ https://issues.apache.org/jira/browse/AMQ-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13771114#comment-13771114 ] Timothy Bish commented on AMQ-4533: --- Running with Dejan's configuration I see the test passing consistently now. Messages stuck in queue with redelivered=true - Key: AMQ-4533 URL: https://issues.apache.org/jira/browse/AMQ-4533 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.7.0 Environment: Fuse Message Broker 5.7.0 Reporter: Jason Shepherd Assignee: Timothy Bish Fix For: 5.9.0 Attachments: AMQ4533_logs.ZIP, AMQ4533Test.java, AMQ4533-test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533-Test.patch, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQ4533TestPatch.txt, AMQFreezeFailingTest.zip, AMQFreeze_logs.zip, AMQFreezeTest-5.8.0.fuse-72-SNAPSHOT-log.zip, AMQFreezeTest-5.9.0.redhat-610084-log.zip, AMQFreezeTest.patch, AMQFreezeTest.zip, AMQFreezeTest.zip, kahaPendingMessages.zip We're getting message stuck in queues with the redelivery flag set to true. We used the following test model: put every 1 second 50 messages sequentially, and after that, the rest of 1000 msgs quickly to INPUT_QUEUE and while starting 25 listeners cosuming from INPUT_QUEUE, which takes about 30 seconds to move the message to RECEIPT_QUEUE, 10 other listeners on RECEIPT_QUEUE consume and counts them. We tried making one of the consumer slow by setting the processing time to 10 seconds (sleep) and putting a heavy load in 500 threads every 1 ms to some other queues the same time. Our test case is attached, you might need to install some dependencies to the local maven repository manually: mvn install:install-file -DgroupId=org.apache.activemq -DartifactId=activemq-core -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-core-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.kahadb -DartifactId=kahadb -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=kahadb-5.7.0.fuse-71-047.jar mvn install:install-file -DgroupId=org.apache.geronimo.management.specs -DartifactId=geronimo-j2ee-management_1.1_spec -Dversion=1.0.1 -Dpackaging=jar -Dfile=geronimo-j2ee-management_1.1_spec-1.0.1.jar mvn install:install-file -DgroupId=org.apache.activemq.pool -DartifactId=activemq-pool -Dversion=5.7.0-fuse-71-047 -Dpackaging=jar -Dfile=activemq-pool-5.7.0.fuse-71-047.jar To run the test, simply use the Maven test target: mvn clean test If the problem occurs the you'll get a message like this in the test results, (target/surefire-reports): java.lang.AssertionError: Still messages in InputQueue expected:0 but was:365 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (AMQ-4727) Unable to add camel routes to activemq running in a karaf container
Noel O'Connor created AMQ-4727: -- Summary: Unable to add camel routes to activemq running in a karaf container Key: AMQ-4727 URL: https://issues.apache.org/jira/browse/AMQ-4727 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.8.0 Environment: jboss-amq-6.0 on Red Hat Enterprise Linux Server release 6.4 (Santiago) Reporter: Noel O'Connor Fix For: 5.9.0 gtully: noconnor: there is a pax exam test on apache trunk that validates the karaf features - see the xml https://github.com/apache/activemq/blob/trunk/activemq-karaf-itest/src/test/resources/org/apache/activemq/karaf/itest/activemq-nd-camel.xml [07:35am] gtully: in 6.0 u can try the same - just embed a context [07:36am] gtully: so modify etc/activemq.xml [07:36am] noconnor: gtully: thanks, trying it now [07:44am] noconnor: gtully: same issue again, bundle context must be specified [07:49am] gtully: noconnor: i see the same thing with the test on trunk… need to investigate that a bit…can u raise an amq issue [07:51am] gtully: noconnor: on trunk that can be reproduced with mvn test -Dtest=ActiveMQBrokerNdCamelFeatureTest in the activemq-karaf-itest module Exception on start: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'activemq' defined in file [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024 /etc/activemq.xml]: Initialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'camel': Invocation of init method failed; nested exception is java.lang.IllegalArgumentException: BundleContext must be specified org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'activemq' defined in file [/opt/jboss-amq/jboss-a-mq-6.0.0.redhat-024/etc/activemq.xml]: I nitialization of bean failed; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'camel': Invocation of init method failed ; nested exception is java.lang.IllegalArgumentException: BundleContext must be specified Also I had to add the activemq-camel feature to org.apache.karaf.features.cfg to get the namespaces resolved -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
