[jira] [Commented] (ARTEMIS-191) Refactor RemoveDestinationTest
[ https://issues.apache.org/jira/browse/ARTEMIS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720360#comment-14720360 ] ASF subversion and git services commented on ARTEMIS-191: - Commit be9959e0bc5d4f46a058c0b02dbbdb1060546301 in activemq-artemis's branch refs/heads/master from [~gaohoward] [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=be9959e ] ARTEMIS-191 Refactor RemoveDestinationTest -Using core api to inspect queue status -Catch command visit() exceptions in order to pass it back to client. -Correct destination add/remove handlings > Refactor RemoveDestinationTest > -- > > Key: ARTEMIS-191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-191 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.3.0 > > > The RemoveDestinationTest is using a vm specific url to creat brokers in > order to test destination removal functionality. Which causes failure because > of its using of internal mechanism to find and launch a broker. > It is very possible to use a 'standard' way to launch a tcp broker to do the > same test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-191) Refactor RemoveDestinationTest
[ https://issues.apache.org/jira/browse/ARTEMIS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720361#comment-14720361 ] ASF GitHub Bot commented on ARTEMIS-191: Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/142 > Refactor RemoveDestinationTest > -- > > Key: ARTEMIS-191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-191 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.3.0 > > > The RemoveDestinationTest is using a vm specific url to creat brokers in > order to test destination removal functionality. Which causes failure because > of its using of internal mechanism to find and launch a broker. > It is very possible to use a 'standard' way to launch a tcp broker to do the > same test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-191) Refactor RemoveDestinationTest
[ https://issues.apache.org/jira/browse/ARTEMIS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720324#comment-14720324 ] ASF GitHub Bot commented on ARTEMIS-191: Github user clebertsuconic commented on the pull request: https://github.com/apache/activemq-artemis/pull/142#issuecomment-135845502 @howardgao I confused the class with AMQDestination under amq on the protocolManager, that's not used anywhere. I see that this is about temp destinations... although I would prefer that code (for deletion) out of the ProtocolManager, since the ProtocolManager is doing a lot more work than what is supposed to be doing... I will merge your commit, although I'm looking to simplify some of these function after we release 1.2. > Refactor RemoveDestinationTest > -- > > Key: ARTEMIS-191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-191 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.3.0 > > > The RemoveDestinationTest is using a vm specific url to creat brokers in > order to test destination removal functionality. Which causes failure because > of its using of internal mechanism to find and launch a broker. > It is very possible to use a 'standard' way to launch a tcp broker to do the > same test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720121#comment-14720121 ] Justin Bertram commented on ARTEMIS-206: I changed org.apache.activemq.artemis.tests.integration.transports.netty.NettyConnectorWithHTTPUpgradeTest to use SSL, and everything appears to work as expected. I didn't make any changes to the NettyConnector. If the client's connector has sslEnabled=true then it will already create the SslHandler and add it to the Netty pipeline to handle the SSL handshake. I've pushed my test code to https://github.com/jbertram/activemq-artemis/tree/ARTEMIS-206 so you can take a look to see if I've done anything incorrectly. There's some kind of thread leak when the test is torn down, but the test passes. > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14719969#comment-14719969 ] Justin Bertram commented on ARTEMIS-206: Nevermind. I got past the SSL handshake issue. Continuing to investigate... > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-216) fix redelivery semantics
[ https://issues.apache.org/jira/browse/ARTEMIS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718604#comment-14718604 ] clebert suconic edited comment on ARTEMIS-216 at 8/28/15 2:05 PM: -- I was actually by coincidence looking at this yesterday... There is an AMQConsumer and an AMQServerConsumer. the AMQConsumer will hold the list of messages belonging to him. Why not to leverage what the server already has? it seems that this is creating a broker within a broker to me. The state should be maintained at the ServerConsumer and redeliveries be handled through QueueImpl as in any other protocol. I propose we refactor the AMQ Consumers to a simpler model on the next release. This JIRA is a good candidate to perform such refactoring. was (Author: clebertsuconic): I was actually by coincidence looking at this yesterday... There is an AMQConsumer and an AMQServerConsumer. the AMQConsumer will hold the list of messages belonging to him. Why not to leverage what the server already has? it seems that this is creating a broker within a broker to me. The state should be maintained at the ServerConsumer and redeliveries be handled through QueueImpl as in any other protocol. I propose we refactor the AMQ Consumers to a simpler model on the 1.3.0 release. This JIRA is a good candidate to perform such refactoring. > fix redelivery semantics > > > Key: ARTEMIS-216 > URL: https://issues.apache.org/jira/browse/ARTEMIS-216 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Andy Taylor >Assignee: Andy Taylor > Fix For: 1.3.0 > > > There are some missing features with redelivery such as setting the delivery > count when redelivered client side and moving to the DLQ. tests to cover this > are: > https://github.com/apache/activemq/blob/master/activemq-unit-test/src/test/java/org/apache/activemq/test/rollback/CloseRollbackRedeliveryQueueTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/NonBlockingConsumerRedeliveryTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/TopicRedeliverTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/QueueRedeliverTest.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-216) fix redelivery semantics
[ https://issues.apache.org/jira/browse/ARTEMIS-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718604#comment-14718604 ] clebert suconic commented on ARTEMIS-216: - I was actually by coincidence looking at this yesterday... There is an AMQConsumer and an AMQServerConsumer. the AMQConsumer will hold the list of messages belonging to him. Why not to leverage what the server already has? it seems that this is creating a broker within a broker to me. The state should be maintained at the ServerConsumer and redeliveries be handled through QueueImpl as in any other protocol. I propose we refactor the AMQ Consumers to a simpler model on the 1.3.0 release. This JIRA is a good candidate to perform such refactoring. > fix redelivery semantics > > > Key: ARTEMIS-216 > URL: https://issues.apache.org/jira/browse/ARTEMIS-216 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Reporter: Andy Taylor >Assignee: Andy Taylor > Fix For: 1.3.0 > > > There are some missing features with redelivery such as setting the delivery > count when redelivered client side and moving to the DLQ. tests to cover this > are: > https://github.com/apache/activemq/blob/master/activemq-unit-test/src/test/java/org/apache/activemq/test/rollback/CloseRollbackRedeliveryQueueTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/NonBlockingConsumerRedeliveryTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/TopicRedeliverTest.java > https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/QueueRedeliverTest.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram reassigned ARTEMIS-206: -- Assignee: Justin Bertram > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil >Assignee: Justin Bertram > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-206) HTTP Upgrade does not work over HTTPS
[ https://issues.apache.org/jira/browse/ARTEMIS-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718586#comment-14718586 ] Justin Bertram commented on ARTEMIS-206: I'm trying to get a test-case set up for this, but I'm having trouble getting the little web server started in org.apache.activemq.artemis.tests.integration.transports.netty.NettyConnectorWithHTTPUpgradeTest.startWebServer() to handle the SSL handshake from the client. You got any ideas on how to implement that? > HTTP Upgrade does not work over HTTPS > - > > Key: ARTEMIS-206 > URL: https://issues.apache.org/jira/browse/ARTEMIS-206 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 >Reporter: Jeff Mesnil > > For security reasons, we need to support creating Artemis connections over > HTTPS Upgrade. > Currently, the Upgrade code works only over HTTP. > We need to also support it over HTTPS for increased security. > This means that the NettyConnector code that deals with httpUpgradeEnabled > must also check if sslEnabled is set. > If that's the case, the GET request to upgrade the connection must be done > over HTTPS instead of HTTP (and add Netty's SSLHandler to handle the SSL > handshake) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ARTEMIS-191) Refactor RemoveDestinationTest
[ https://issues.apache.org/jira/browse/ARTEMIS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718481#comment-14718481 ] ASF GitHub Bot commented on ARTEMIS-191: GitHub user gaohoward opened a pull request: https://github.com/apache/activemq-artemis/pull/142 ARTEMIS-191 Refactor RemoveDestinationTest -Using core api to inspect queue status -Catch command visit() exceptions in order to pass it back to client. -Correct destination add/remove handlings You can merge this pull request into a Git repository by running: $ git pull https://github.com/gaohoward/activemq-artemis openwire-work3 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/142.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #142 commit be9959e0bc5d4f46a058c0b02dbbdb1060546301 Author: Howard Gao Date: 2015-08-28T12:33:38Z ARTEMIS-191 Refactor RemoveDestinationTest -Using core api to inspect queue status -Catch command visit() exceptions in order to pass it back to client. -Correct destination add/remove handlings > Refactor RemoveDestinationTest > -- > > Key: ARTEMIS-191 > URL: https://issues.apache.org/jira/browse/ARTEMIS-191 > Project: ActiveMQ Artemis > Issue Type: Sub-task > Components: OpenWire >Affects Versions: 1.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 1.3.0 > > > The RemoveDestinationTest is using a vm specific url to creat brokers in > order to test destination removal functionality. Which causes failure because > of its using of internal mechanism to find and launch a broker. > It is very possible to use a 'standard' way to launch a tcp broker to do the > same test. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ARTEMIS-216) fix redelivery semantics
Andy Taylor created ARTEMIS-216: --- Summary: fix redelivery semantics Key: ARTEMIS-216 URL: https://issues.apache.org/jira/browse/ARTEMIS-216 Project: ActiveMQ Artemis Issue Type: Sub-task Reporter: Andy Taylor Assignee: Andy Taylor There are some missing features with redelivery such as setting the delivery count when redelivered client side and moving to the DLQ. tests to cover this are: https://github.com/apache/activemq/blob/master/activemq-unit-test/src/test/java/org/apache/activemq/test/rollback/CloseRollbackRedeliveryQueueTest.java https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/NonBlockingConsumerRedeliveryTest.java https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/TopicRedeliverTest.java https://github.com/apache/activemq/blob/master/activemq-unit-tests/src/test/java/org/apache/activemq/usecases/QueueRedeliverTest.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718237#comment-14718237 ] Huang Wen Hui edited comment on ARTEMIS-211 at 8/28/15 9:01 AM: In BindingsImpl.addBinding(), the binding should only add once into bindings? The patch "BindingsImpl.java.patch" may fixed it. was (Author: huanghwh): In BindingsImpl.addBinding(), the binding should only add once into bindings? This patch may fixed it. > Memory leak using wildcard topic > > > Key: ARTEMIS-211 > URL: https://issues.apache.org/jira/browse/ARTEMIS-211 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: FreeBSD 10.2+ARTEMIS >Reporter: Huang Wen Hui >Assignee: Justin Bertram > Attachments: BindingsImpl.java.patch, Receiver1.java, Receiver2.java, > Sender.java, artemis.log.gz, broker.xml > > > 1. I set up broker.xml use PAGE: > > > > jms.queue.DLQ > jms.queue.ExpiryQueue > 0 > 2097152 > 10485760 > > 10 > PAGE > > > and add 2 topics: > > > 2. before run broker, open DEBUG: > logger.org.apache.activemq.artemis.core.server.level=DEBUG > 3. run Sender.java > 4. run Receiver1.java with rts.* first, and then run Receiver2.java with > rts.pick. > 5. kill Receiver1 and Receiver2. > 6. after about 20 mins, OutOfMemory: > 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: > Connection failure has been detected: AMQ119014: Did not receive data from > /127.0.0.1:36351. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for more > information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] > 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed > out waiting for netty channel to close > 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > Exception in thread "qtp1326393666-134" Exception in thread "ActiveMQ > Artemis Server Shutdown Timer" Exception in thread "qtp1326393666-130" > Exception in thread "Thread-9 > (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301)" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "qtp1326393666-134" > java.lang.OutOfMemoryError: Java heap space > 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception > in the selector loop.: java.lang.OutOfMemoryError: Java heap space > 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error > on connection failure check: java.lang.OutOfMemoryError: Java heap space > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) > at java.lang.StringCoding.encode(StringCoding.java:344) > at java.lang.String.getBytes(String.java:906) > at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) > at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) > at java.io.File.exists(File.java:819) > at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "Thread-3 (activemq-netty-threads-2123444693)" Exception > in thread "activemq-expiry-reaper-thread" java.lang.OutOfMemoryError: Java > heap space > java.lang.OutOfMemor
[jira] [Updated] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Huang Wen Hui updated ARTEMIS-211: -- Attachment: BindingsImpl.java.patch > Memory leak using wildcard topic > > > Key: ARTEMIS-211 > URL: https://issues.apache.org/jira/browse/ARTEMIS-211 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: FreeBSD 10.2+ARTEMIS >Reporter: Huang Wen Hui >Assignee: Justin Bertram > Attachments: BindingsImpl.java.patch, Receiver1.java, Receiver2.java, > Sender.java, artemis.log.gz, broker.xml > > > 1. I set up broker.xml use PAGE: > > > > jms.queue.DLQ > jms.queue.ExpiryQueue > 0 > 2097152 > 10485760 > > 10 > PAGE > > > and add 2 topics: > > > 2. before run broker, open DEBUG: > logger.org.apache.activemq.artemis.core.server.level=DEBUG > 3. run Sender.java > 4. run Receiver1.java with rts.* first, and then run Receiver2.java with > rts.pick. > 5. kill Receiver1 and Receiver2. > 6. after about 20 mins, OutOfMemory: > 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: > Connection failure has been detected: AMQ119014: Did not receive data from > /127.0.0.1:36351. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for more > information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] > 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed > out waiting for netty channel to close > 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > Exception in thread "qtp1326393666-134" Exception in thread "ActiveMQ > Artemis Server Shutdown Timer" Exception in thread "qtp1326393666-130" > Exception in thread "Thread-9 > (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301)" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "qtp1326393666-134" > java.lang.OutOfMemoryError: Java heap space > 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception > in the selector loop.: java.lang.OutOfMemoryError: Java heap space > 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error > on connection failure check: java.lang.OutOfMemoryError: Java heap space > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) > at java.lang.StringCoding.encode(StringCoding.java:344) > at java.lang.String.getBytes(String.java:906) > at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) > at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) > at java.io.File.exists(File.java:819) > at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "Thread-3 (activemq-netty-threads-2123444693)" Exception > in thread "activemq-expiry-reaper-thread" java.lang.OutOfMemoryError: Java > heap space > java.lang.OutOfMemoryError: Java heap space > 15:21:04,952 WARNING [io.netty.channel.DefaultChannelPipeline] An > exceptionCaught() event was fired, and it reached at the tail of the > pipeline. It usually means the last handler in the pipeline did not handle > the exception.: io.netty.channel.ChannelPipelineException: > org.apache.activemq.a
[jira] [Commented] (ARTEMIS-211) Memory leak using wildcard topic
[ https://issues.apache.org/jira/browse/ARTEMIS-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14718237#comment-14718237 ] Huang Wen Hui commented on ARTEMIS-211: --- In BindingsImpl.addBinding(), the binding should only add once into bindings? This patch may fixed it. > Memory leak using wildcard topic > > > Key: ARTEMIS-211 > URL: https://issues.apache.org/jira/browse/ARTEMIS-211 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 1.0.0 > Environment: FreeBSD 10.2+ARTEMIS >Reporter: Huang Wen Hui >Assignee: Justin Bertram > Attachments: BindingsImpl.java.patch, Receiver1.java, Receiver2.java, > Sender.java, artemis.log.gz, broker.xml > > > 1. I set up broker.xml use PAGE: > > > > jms.queue.DLQ > jms.queue.ExpiryQueue > 0 > 2097152 > 10485760 > > 10 > PAGE > > > and add 2 topics: > > > 2. before run broker, open DEBUG: > logger.org.apache.activemq.artemis.core.server.level=DEBUG > 3. run Sender.java > 4. run Receiver1.java with rts.* first, and then run Receiver2.java with > rts.pick. > 5. kill Receiver1 and Receiver2. > 6. after about 20 mins, OutOfMemory: > 15:18:28,462 WARN [org.apache.activemq.artemis.core.client] AMQ212037: > Connection failure has been detected: AMQ119014: Did not receive data from > /127.0.0.1:36351. It is likely the client has exited or crashed without > closing its connection, or the network between the server and client has > failed. You also might have configured connection-ttl and > client-failure-check-period incorrectly. Please check user manual for more > information. The connection will now be closed. [code=CONNECTION_TIMEDOUT] > 15:18:41,090 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:18:57,554 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:18:53,474 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fafb41-4af7-11e5-8680-adb2aefa8c20 > 15:19:03,751 WARN [org.apache.activemq.artemis.core.server] AMQ222061: > Client connection failed, clearing up resources for session > a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:11,228 WARN [org.apache.activemq.artemis.core.server] AMQ222107: > Cleared up resources for session a3fc81e2-4af7-11e5-8680-adb2aefa8c20 > 15:19:29,926 WARN [org.apache.activemq.artemis.core.client] AMQ212041: Timed > out waiting for netty channel to close > 15:19:34,166 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > 15:20:10,078 DEBUG [org.apache.activemq.artemis.core.server] Cannot expire > from jms.queue.ExpiryQueue into jms.queue.ExpiryQueue > Exception in thread "qtp1326393666-134" Exception in thread "ActiveMQ > Artemis Server Shutdown Timer" Exception in thread "qtp1326393666-130" > Exception in thread "Thread-9 > (ActiveMQ-server-ActiveMQServerImpl::serverUUID=9e8aecec-4a4d-11e5-b7c8-a3ebfe3193a3-589835301)" > > Exception: java.lang.OutOfMemoryError thrown from the > UncaughtExceptionHandler in thread "qtp1326393666-134" > java.lang.OutOfMemoryError: Java heap space > 15:20:28,493 WARNING [io.netty.channel.nio.NioEventLoop] Unexpected exception > in the selector loop.: java.lang.OutOfMemoryError: Java heap space > 15:20:37,701 WARN [org.apache.activemq.artemis.core.server] AMQ222082: error > on connection failure check: java.lang.OutOfMemoryError: Java heap space > at java.lang.StringCoding$StringEncoder.encode(StringCoding.java:300) > at java.lang.StringCoding.encode(StringCoding.java:344) > at java.lang.String.getBytes(String.java:906) > at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) > at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:242) > at java.io.File.exists(File.java:819) > at org.apache.activemq.artemis.cli.commands.Run$1.run(Run.java:134) > at java.util.TimerThread.mainLoop(Timer.java:555) > at java.util.TimerThread.run(Timer.java:505) > java.lang.OutOfMemoryError: Java heap space > java.lang.OutOfMemoryError: Java heap space > Exception in thread "Thread-3 (activemq-netty-threads-2123444693)" Exception > in thread "activemq-expiry-reaper-thread" java.lang.OutOfMemoryError: Java > heap space > java.lang.OutOfMemoryError: Java heap space > 15:21:04,952 WARNING [io.netty.channel.DefaultChannelPipeline] An > exceptionCaught() event was fired, and it reached at the tail of the > pipeline. It usually means the last ha
[jira] [Updated] (AMQ-5949) org.apache.activemq.network.jms.OutboundQueueBridge does not provide guaranteed message forwarding
[ https://issues.apache.org/jira/browse/AMQ-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Nisbet updated AMQ-5949: Description: When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 to result in message loss if the connection to destination server is unreliable. (messages that are not delivered to destination within maxSendRetries are still acknowledged as having been consumed by processing of later messages) Is it possible for the org.apache.activemq.network.jms.DestinationBridge.onMessage() implementation to interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity? was: When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector bean I have observed the default ReconnectionPolicy.maxSendRetries value of 10 to result in message loss if the connection to destination server is unreliable. (messages that are not delivered to destination within maxSendRetries are still acknowledged as having been consumed by processing of later messages) Is it possible for the DestinationBridge onMessage() implementation to interpret a ReconnectionPolicy.maxSendRetries property value of -1 as infinity? > org.apache.activemq.network.jms.OutboundQueueBridge does not provide > guaranteed message forwarding > -- > > Key: AMQ-5949 > URL: https://issues.apache.org/jira/browse/AMQ-5949 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.2 > Environment: WebLogic 10.3.6, JRockit JDK 1.6 >Reporter: Ben Nisbet > Fix For: NEEDS_REVIEW > > > When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector > bean I have observed the default ReconnectionPolicy.maxSendRetries value of > 10 to result in message loss if the connection to destination server is > unreliable. (messages that are not delivered to destination within > maxSendRetries are still acknowledged as having been consumed by processing > of later messages) > Is it possible for the > org.apache.activemq.network.jms.DestinationBridge.onMessage() implementation > to interpret a ReconnectionPolicy.maxSendRetries property value of -1 as > infinity? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5949) org.apache.activemq.network.jms.OutboundQueueBridge does not provide guaranteed message forwarding
[ https://issues.apache.org/jira/browse/AMQ-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Nisbet updated AMQ-5949: Fix Version/s: NEEDS_REVIEW > org.apache.activemq.network.jms.OutboundQueueBridge does not provide > guaranteed message forwarding > -- > > Key: AMQ-5949 > URL: https://issues.apache.org/jira/browse/AMQ-5949 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.2 > Environment: WebLogic 10.3.6, JRockit JDK 1.6 >Reporter: Ben Nisbet > Fix For: NEEDS_REVIEW > > > When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector > bean I have observed the default ReconnectionPolicy.maxSendRetries value of > 10 to result in message loss if the connection to destination server is > unreliable. (messages that are not delivered to destination within > maxSendRetries are still acknowledged as having been consumed by processing > of later messages) > Is it possible for the DestinationBridge onMessage() implementation to > interpret a ReconnectionPolicy.maxSendRetries property value of -1 as > infinity? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (AMQ-5949) org.apache.activemq.network.jms.OutboundQueueBridge does not provide guaranteed message forwarding
[ https://issues.apache.org/jira/browse/AMQ-5949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Nisbet updated AMQ-5949: Fix Version/s: (was: 5.10.3) > org.apache.activemq.network.jms.OutboundQueueBridge does not provide > guaranteed message forwarding > -- > > Key: AMQ-5949 > URL: https://issues.apache.org/jira/browse/AMQ-5949 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Affects Versions: 5.10.2 > Environment: WebLogic 10.3.6, JRockit JDK 1.6 >Reporter: Ben Nisbet > Fix For: NEEDS_REVIEW > > > When using an OutboundQueueBridge associated with a SimpleJmsQueueConnector > bean I have observed the default ReconnectionPolicy.maxSendRetries value of > 10 to result in message loss if the connection to destination server is > unreliable. (messages that are not delivered to destination within > maxSendRetries are still acknowledged as having been consumed by processing > of later messages) > Is it possible for the DestinationBridge onMessage() implementation to > interpret a ReconnectionPolicy.maxSendRetries property value of -1 as > infinity? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
