[jira] [Commented] (AMQ-4595) QueueBrowser hangs when browsing large queues
[ https://issues.apache.org/jira/browse/AMQ-4595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731719#comment-13731719 ] Torsten Mielke commented on AMQ-4595: - @Nicholas - Thx for the update. Will do. QueueBrowser hangs when browsing large queues - Key: AMQ-4595 URL: https://issues.apache.org/jira/browse/AMQ-4595 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Environment: All Reporter: Nicholas Rahn Assignee: Timothy Bish Priority: Critical Labels: QueueBrowser Fix For: 5.9.0 Attachments: AMQ4595Test.java, AMQ580BrowsingBug.java, amq-test-20130621T155120.log When trying to browse a queue with a QueueBrowser, the browsing will hang and never complete. This appears to happen only with a lot of message in the queue. 1000 messages works correctly, but 1 hangs. I have attached a unit test that exhibits the problem. Change the messageToSend variable in the test method to see the difference between small queue size and large queue size. I've attached the unit test code as well as the output from one of the runs with 1 messages. -- 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-4531) TcpTransportServer can leak FDs when maximumConnection is set and the limit exceeded
[ https://issues.apache.org/jira/browse/AMQ-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731760#comment-13731760 ] Jaewoong Choi commented on AMQ-4531: Could you point to the changes/fix you made? Also wonder if this bug exists with 5.7.0 as well. I'm seeing a similar fd leak issues especially with huge amount of connections. TcpTransportServer can leak FDs when maximumConnection is set and the limit exceeded Key: AMQ-4531 URL: https://issues.apache.org/jira/browse/AMQ-4531 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.8.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.9.0 We don't close accepted sockets when we reach maximumConnections which can lead to leaking File Descriptors over time. -- 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-4531) TcpTransportServer can leak FDs when maximumConnection is set and the limit exceeded
[ https://issues.apache.org/jira/browse/AMQ-4531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731847#comment-13731847 ] Timothy Bish commented on AMQ-4531: --- Look under the source tab of this issue for a list of changed files, you can even generate a patch file from there. TcpTransportServer can leak FDs when maximumConnection is set and the limit exceeded Key: AMQ-4531 URL: https://issues.apache.org/jira/browse/AMQ-4531 Project: ActiveMQ Issue Type: Bug Components: Transport Affects Versions: 5.8.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.9.0 We don't close accepted sockets when we reach maximumConnections which can lead to leaking File Descriptors over time. -- 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-4670) DurableSubDelayedUnsubscribeTest.testProcess fails intermittently
Kevin Earls created AMQ-4670: Summary: DurableSubDelayedUnsubscribeTest.testProcess fails intermittently Key: AMQ-4670 URL: https://issues.apache.org/jira/browse/AMQ-4670 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor This test fails intermittently as shown below. This occurs because the test assumes all clients have finished, where under certain circumstances there could still be one active client that is sleeping. java.lang.AssertionError: should have only one inactiveSubscriber subscribed expected:1 but was:2 at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:555) at org.apache.activemq.usecases.DurableSubDelayedUnsubscribeTest.testProcess(DurableSubDelayedUnsubscribeTest.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:81) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) -- 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-4670) DurableSubDelayedUnsubscribeTest.testProcess fails intermittently
[ https://issues.apache.org/jira/browse/AMQ-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Earls updated AMQ-4670: - Attachment: AMQ-4670.patch DurableSubDelayedUnsubscribeTest.testProcess fails intermittently - Key: AMQ-4670 URL: https://issues.apache.org/jira/browse/AMQ-4670 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor Attachments: AMQ-4670.patch This test fails intermittently as shown below. This occurs because the test assumes all clients have finished, where under certain circumstances there could still be one active client that is sleeping. java.lang.AssertionError: should have only one inactiveSubscriber subscribed expected:1 but was:2 at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:555) at org.apache.activemq.usecases.DurableSubDelayedUnsubscribeTest.testProcess(DurableSubDelayedUnsubscribeTest.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:81) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) -- 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-4665) Failover with client ack mode consumer can loose a message auto acked as a duplicate
[ https://issues.apache.org/jira/browse/AMQ-4665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-4665. - Resolution: Fixed fix in http://svn.apache.org/r1511307 auto ack on duplicate now replaced with poison ack with poison cause property set. Duplicates need to be flagged as problems in the normal case. Client ack mode now allows replay b/c consumed and undelivered are rolledback in a failover interrupt. Failover with client ack mode consumer can loose a message auto acked as a duplicate Key: AMQ-4665 URL: https://issues.apache.org/jira/browse/AMQ-4665 Project: ActiveMQ Issue Type: Bug Components: JMS client Affects Versions: 5.8.0 Reporter: Gary Tully Assignee: Gary Tully Labels: clientAck, duplicate, failover Fix For: 5.9.0 with a client ack consumer and failover after receipt but before message.ack can result in a missed message when the message is redispatched and auto acked as a duplicate. Failover interrupt should clear dispatched and unconsumed messages so that they can get redelivered. auto-acking a duplicate seems over eager. think best to poison pill and now that we can include a cause property it will be possible to differentiate. -- 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-4671) REGRESSION: InvalidDestinationException should be thrown on Session.unsubscribe that has no sub
Timothy Bish created AMQ-4671: - Summary: REGRESSION: InvalidDestinationException should be thrown on Session.unsubscribe that has no sub Key: AMQ-4671 URL: https://issues.apache.org/jira/browse/AMQ-4671 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.9.0 When calling unsubscribe on Session with invalid subscription as a parameter InvalidDestinationException should be thrown. AMQ-4000 fix broke this. -- 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-4671) REGRESSION: InvalidDestinationException should be thrown on Session.unsubscribe that has no sub
[ https://issues.apache.org/jira/browse/AMQ-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-4671. --- Resolution: Fixed fixed on trunk, needed to ensure the remove propagates past the advisory broker even if there is no subscription so that the proper exceptions are thrown. REGRESSION: InvalidDestinationException should be thrown on Session.unsubscribe that has no sub --- Key: AMQ-4671 URL: https://issues.apache.org/jira/browse/AMQ-4671 Project: ActiveMQ Issue Type: Bug Components: Broker Affects Versions: 5.8.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 5.9.0 When calling unsubscribe on Session with invalid subscription as a parameter InvalidDestinationException should be thrown. AMQ-4000 fix broke this. -- 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-4656) Pending Queue Counter is incorrect when using durable topics
[
https://issues.apache.org/jira/browse/AMQ-4656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13732058#comment-13732058
]
Dejan Bosanac commented on AMQ-4656:
The first stab at fixing this is in svn revision 1511333. I changed the way
keepDurableSubsActive works, by not stopping/starting the cursor when
subscription (de)activates. This is a natural way in how this feature should
work and also simplifies things a bit.
I verified the fix by running all tests with that has durable in the name, but
we should wait for the full nightly build to see if something is broker.
Pending Queue Counter is incorrect when using durable topics
Key: AMQ-4656
URL: https://issues.apache.org/jira/browse/AMQ-4656
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.8.0
Reporter: Timothy Bish
Assignee: Dejan Bosanac
Fix For: 5.9.0
Attachments: AMQ4656Test.java
When using a durable topics the Pending Queue Counter provides an incorrect
value for pending messages.
Steps to recreate
Set up the durable subscriber
{noformat}
ant consumer -Durl=tcp://localhost:61616 -Dtopic=true -Dsubject=MYSUB
-Ddurable=true -Dmax=2
{noformat}
Stop the subscriber
Send 20 persistent messages
{noformat}
ant producer -Ddurable=true -Durl=tcp://localhost:61616 -Dtopic=true
-Dsubject=MYSUB -Dmax=20
{noformat}
Consume 2 messages
{noformat}
ant consumer -Durl=tcp://localhost:61616 -Dtopic=true -Dsubject=MYSUB
-Ddurable=true -Dmax=2
{noformat}
View the counter stats.
The result is the following:
{noformat}
Pending Queue Size = 38
Dispatched Queue Size = 0
Dispatched Counter = 20
Enqueue Counter = 20
Dequeue Counter = 2
{noformat}
--
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-4672) [JMS Client] Set the SNI field on SSL connections
Hiram Chirino created AMQ-4672: -- Summary: [JMS Client] Set the SNI field on SSL connections Key: AMQ-4672 URL: https://issues.apache.org/jira/browse/AMQ-4672 Project: ActiveMQ Issue Type: Bug 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-4670) DurableSubDelayedUnsubscribeTest.testProcess fails intermittently
[ https://issues.apache.org/jira/browse/AMQ-4670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13732070#comment-13732070 ] Timothy Bish commented on AMQ-4670: --- Looks good, fix applied, test passed a couple times here. DurableSubDelayedUnsubscribeTest.testProcess fails intermittently - Key: AMQ-4670 URL: https://issues.apache.org/jira/browse/AMQ-4670 Project: ActiveMQ Issue Type: Bug Components: Test Cases Reporter: Kevin Earls Priority: Minor Attachments: AMQ-4670.patch This test fails intermittently as shown below. This occurs because the test assumes all clients have finished, where under certain circumstances there could still be one active client that is sleeping. java.lang.AssertionError: should have only one inactiveSubscriber subscribed expected:1 but was:2 at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:743) at org.junit.Assert.assertEquals(Assert.java:118) at org.junit.Assert.assertEquals(Assert.java:555) at org.apache.activemq.usecases.DurableSubDelayedUnsubscribeTest.testProcess(DurableSubDelayedUnsubscribeTest.java:131) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:81) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) -- 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] (AMQCPP-505) For SSL connections ensure the SNI field is set.
Timothy Bish created AMQCPP-505: --- Summary: For SSL connections ensure the SNI field is set. Key: AMQCPP-505 URL: https://issues.apache.org/jira/browse/AMQCPP-505 Project: ActiveMQ C++ Client Issue Type: Bug Components: Transports Affects Versions: 3.7.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 3.8.0 Provide a way in the Decaf OpenSSL implementation to set the SNI field and then ensure it gets set in the SSL transport layer. -- 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-4673) Application that uses activemq-camel fails deploying to GlassFish v4
Kevin Schmidt created AMQ-4673: -- Summary: Application that uses activemq-camel fails deploying to GlassFish v4 Key: AMQ-4673 URL: https://issues.apache.org/jira/browse/AMQ-4673 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.6.0 Environment: Mac OS X, Java 1.7.0_25, GlassFish v4 Reporter: Kevin Schmidt Attachments: CamelEndpointLoader.patch I have an application that uses activemq-camel and deploys/works fine with GlassFish v3. I tried to deploy the same application on GlassFish v4 and get this error: remote failure: Error occurred during deployment: Exception while deploying the app [appname] : The lifecycle method [afterPropertiesSet] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public void org.apache.activemq.camel.component.CamelEndpointLoader.afterPropertiesSet() throws java.lang.Exception] of type [METHOD]. Please see server.log for more details. Command deploy failed. It appears that CamelEndpointLoader has a @PostConstruct method that throws an Exception and per the Java EE spec that isn't allowed. Apparently GlassFish v3 was lenient but v4 is not. Looking at the code, it is easy to fix. The afterPropertiesSet method just needs to catch the exceptions from addQueue/addTopic and log them at the end of the method like it does earlier in the method. If a failure to add these during the method should actually be considered a failure, then something like IllegalStateException or another unchecked exception should be thrown instead. This fix has been tested and verified to get past the problem. -- 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-4673) Application that uses activemq-camel fails deploying to GlassFish v4
[ https://issues.apache.org/jira/browse/AMQ-4673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Schmidt updated AMQ-4673: --- Attachment: CamelEndpointLoader.patch Application that uses activemq-camel fails deploying to GlassFish v4 Key: AMQ-4673 URL: https://issues.apache.org/jira/browse/AMQ-4673 Project: ActiveMQ Issue Type: Bug Components: activemq-camel Affects Versions: 5.6.0 Environment: Mac OS X, Java 1.7.0_25, GlassFish v4 Reporter: Kevin Schmidt Attachments: CamelEndpointLoader.patch I have an application that uses activemq-camel and deploys/works fine with GlassFish v3. I tried to deploy the same application on GlassFish v4 and get this error: remote failure: Error occurred during deployment: Exception while deploying the app [appname] : The lifecycle method [afterPropertiesSet] must not throw a checked exception. Related annotation information: annotation [@javax.annotation.PostConstruct()] on annotated element [public void org.apache.activemq.camel.component.CamelEndpointLoader.afterPropertiesSet() throws java.lang.Exception] of type [METHOD]. Please see server.log for more details. Command deploy failed. It appears that CamelEndpointLoader has a @PostConstruct method that throws an Exception and per the Java EE spec that isn't allowed. Apparently GlassFish v3 was lenient but v4 is not. Looking at the code, it is easy to fix. The afterPropertiesSet method just needs to catch the exceptions from addQueue/addTopic and log them at the end of the method like it does earlier in the method. If a failure to add these during the method should actually be considered a failure, then something like IllegalStateException or another unchecked exception should be thrown instead. This fix has been tested and verified to get past the problem. -- 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] (AMQCPP-505) For SSL connections ensure the SNI field is set.
[ https://issues.apache.org/jira/browse/AMQCPP-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQCPP-505. - Resolution: Fixed Uses the SSL_set_tlsext_host_name() method we now propagate the host value from the URI down to the SSL socket to configure the SNI field. For SSL connections ensure the SNI field is set. Key: AMQCPP-505 URL: https://issues.apache.org/jira/browse/AMQCPP-505 Project: ActiveMQ C++ Client Issue Type: Bug Components: Transports Affects Versions: 3.7.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: 3.8.0 Provide a way in the Decaf OpenSSL implementation to set the SNI field and then ensure it gets set in the SSL transport layer. -- 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-4663) Dead lock between ActiveMQ Task and InactivityMonitor Async Task
[ https://issues.apache.org/jira/browse/AMQ-4663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-4663. - Resolution: Incomplete No test to validate and no feedback on latest release tests. Dead lock between ActiveMQ Task and InactivityMonitor Async Task Key: AMQ-4663 URL: https://issues.apache.org/jira/browse/AMQ-4663 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.5.1 Environment: Cent Os 5.8 x 64, java version 1.6.0_22 Reporter: Bhushan Shelke Attachments: tdump_29July2013.tdump.tar.gz Got deadlock following is snippet thread dump Deadlock Detection: Found one Java-level deadlock: = Camel Thread #0 - JmsConsumer[abc/SendQueue]: waiting for ownable synchronizer 0x000799ce4690, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@18b866d9 InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@18b866d9: waiting to lock Monitor@0x2aaabca91580 (Object@0x00078822c168, a java/lang/Object), which is held by Camel Thread #0 - JmsConsumer[abc/SendQueue] Found one Java-level deadlock: = ActiveMQ Task-65635: waiting for ownable synchronizer 0x000796e194a0, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@9f25d81 InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@9f25d81: waiting to lock Monitor@0x2aaab87142b0 (Object@0x000796db8108, a java/lang/Object), which is held by ActiveMQ Task-65635 Found one Java-level deadlock: = ActiveMQ Task-90985: waiting for ownable synchronizer 0x000799c683a0, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@561187fc InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@561187fc: waiting to lock Monitor@0x2aaabcda2b60 (Object@0x0007881e5290, a java/lang/Object), which is held by ActiveMQ Task-90985 Found one Java-level deadlock: = InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@29be1c47: waiting to lock Monitor@0x2aaabd1be958 (Object@0x0007988da1f0, a java/lang/Object), which is held by ActiveMQ Task-83387 ActiveMQ Task-83387: waiting for ownable synchronizer 0x000799c0c778, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@29be1c47 Found one Java-level deadlock: = InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@7e552ef2: waiting to lock Monitor@0x2aaab76bb4a0 (Object@0x0007988cdd00, a java/lang/Object), which is held by ActiveMQ Task-83410 ActiveMQ Task-83410: waiting for ownable synchronizer 0x000799c05410, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@7e552ef2 Found one Java-level deadlock: = ActiveMQ Task-79893: waiting for ownable synchronizer 0x000799bde768, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@210cd391 InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@210cd391: waiting to lock Monitor@0x2aaabdbf60e0 (Object@0x0007975a2a88, a java/lang/Object), which is held by ActiveMQ Task-79893 Found one Java-level deadlock: = ActiveMQ Task-91581: waiting for ownable synchronizer 0x000799c73b58, (a java/util/concurrent/locks/ReentrantReadWriteLock$NonfairSync), which is held by InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@67485042 InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@67485042: waiting to lock Monitor@0x2aaabc55da70 (Object@0x0007988d3660, a java/lang/Object), which is held by ActiveMQ Task-91581 Found a total of 7 deadlocks. -- 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-4674) ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol
Paul Gale created AMQ-4674: -- Summary: ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol Key: AMQ-4674 URL: https://issues.apache.org/jira/browse/AMQ-4674 Project: ActiveMQ Issue Type: New Feature Affects Versions: 5.8.0 Reporter: Paul Gale Fix For: NEEDS_REVIEWED Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! -- 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-4674) ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol
[ https://issues.apache.org/jira/browse/AMQ-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gale updated AMQ-4674: --- Fix Version/s: (was: NEEDS_REVIEWED) 5.9.0 ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol - Key: AMQ-4674 URL: https://issues.apache.org/jira/browse/AMQ-4674 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.8.0 Reporter: Paul Gale Labels: easyfix Fix For: 5.9.0 Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! -- 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-4674) ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol
[ https://issues.apache.org/jira/browse/AMQ-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gale updated AMQ-4674: --- Issue Type: Bug (was: New Feature) ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol - Key: AMQ-4674 URL: https://issues.apache.org/jira/browse/AMQ-4674 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.8.0 Reporter: Paul Gale Labels: easyfix Fix For: NEEDS_REVIEWED Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! -- 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-4674) ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol
[ https://issues.apache.org/jira/browse/AMQ-4674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gale updated AMQ-4674: --- Description: Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. As the broker aggressively enforces the heart beat timeouts false failover attempts can result. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! was: Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! ActiveMQ 5.x does not support the notion of a grace-period for heart beats as supported by the STOMP protocol - Key: AMQ-4674 URL: https://issues.apache.org/jira/browse/AMQ-4674 Project: ActiveMQ Issue Type: Bug Affects Versions: 5.8.0 Reporter: Paul Gale Labels: easyfix Fix For: 5.9.0 Regarding the configuration of heart beating the STOMP protocol spec states: - because of timing inaccuracies, the receiver SHOULD be tolerant and take into account an error margin However, it appears that ActiveMQ 5.x is not tolerant of any error margin. Despite the fact that the spec says SHOULD rather than MUST it would make the implementation of STOMP clients easier if the error margin was published. As the broker aggressively enforces the heart beat timeouts false failover attempts can result. Apparently Apollo supports an error margin of 1.5x the configured heart beat. If it could be made configurable that would be even better! -- 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
