[jira] [Commented] (ARTEMIS-306) ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault when executed against Artemis

[Petr Matousek (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018076#comment-15018076
 ] 

Petr Matousek commented on ARTEMIS-306:
---

please cooperate to identify which party needs the fix.

> ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault 
> when executed against Artemis
> --
>
> Key: ARTEMIS-306
> URL: https://issues.apache.org/jira/browse/ARTEMIS-306
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, OpenWire
>Affects Versions: 1.1.0
> Environment: Machine OS: Rhel 6.7 i686 and x86_64
> Client: ActiveMQ CPP 3.9.0
>Reporter: Petra Svobodova
> Attachments: terminal_transcript
>
>
> CMS tests that leads to client segmentation fault:  
> N8activemq4test8openwire26OpenwireXATransactionsTestE::testSendReceiveTransactedBatchesSegmentation
>  fault (core dumped)  
> N8activemq4test8openwire36OpenWireCmsSendWithAsyncCallbackTestE::testAsyncCallbackIsFasterSegmentation
>  fault (core dumped) - Occasionally only
> other failing test from the suite:  
> N8activemq4test8openwire21OpenwireAdvisorysTestE::testConnectionAdvisories. : 
> assertionF  
> N8activemq4test8openwire30OpenwireEnhancedConnectionTestE::testDestinationSourceGetters.
>  : assertionF  
> N8activemq4test8openwire22OpenwireMapMessageTestE::testEmptyMapSendReceive. : 
> assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testTextMessageCompression.
>  : assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testStreamMessageCompression.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testReceiveBrowseReceive.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testQueueBrowserWith2Consumers.
>  : assertionF  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testDLQHandling. : 
> errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryReceiveNoCommit.
>  : errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryOnMessageNoCommit.
>  : errorE  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleConnections. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleSessions. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testReceiveAlreadyInQueue. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testWithZeroConsumerPrefetchWithInFlightExpiration.
>  : errorE  N8activemq4test8openwire18OpenwireSimpleTestE::tesstStreamMessage. 
> : assertionF  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testBasics. : errorE  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testTwoConnections. : 
> assertionF  
> N8activemq4test8openwire23OpenwireTransactionTestE::testSendSessionClose. : 
> errorE  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveAutoAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveClinetAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveTransacted.
>  : assertionF
> Steps to reproduce:
> 1.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-artemis/1.1.0/apache-artemis-1.1.0-bin.zip
> 2.) unzip apache-artemis-1.1.0-bin.zip
> 3.) cd apache-artemis-1.1.0/bin/
> 4.) ./artemis create broker110 --data /tmp/artemis/broker110 
> --allow-anonymous --user pematous --password pematous ../runtime/broker110
> 5.) 
> /root/A-MQ/r7.0.0/upstream/apache-artemis-1.1.0/runtime/broker110/bin/artemis-service
>  start
> 6.) cd -
> 7.) cd activemq-cpp-library-3.9.0/src/test-integration/
> 8.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-cpp/3.9.0/activemq-cpp-library-3.9.0-src.tar.gz
> 9.) tar -xf activemq-cpp-library-3.9.0-src.tar.gz
> 10.) cd activemq-cpp-library-3.9.0
> 11.) ./configure
> 12.) make check
> 13.) cd src/test-integration
> 14.) ./activemq-test-integration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQCPP-587) ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault when executed against Artemis

[Petra Svobodova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQCPP-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Petra Svobodova updated AMQCPP-587:
---
Attachment: terminal_transcript

Look at the terminal transcript, please.

> ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault 
> when executed against Artemis
> --
>
> Key: AMQCPP-587
> URL: https://issues.apache.org/jira/browse/AMQCPP-587
> Project: ActiveMQ C++ Client
>  Issue Type: Bug
>  Components: CMS Impl
>Affects Versions: 3.9.0
> Environment: Machine OS: Rhel 6.7 i686 and x86_64
> Broker: Artemis 1.1.0
>Reporter: Petra Svobodova
>Assignee: Timothy Bish
> Attachments: terminal_transcript
>
>
> CMS tests that leads to client segmentation fault:  
> N8activemq4test8openwire26OpenwireXATransactionsTestE::testSendReceiveTransactedBatchesSegmentation
>  fault (core dumped)  
> N8activemq4test8openwire36OpenWireCmsSendWithAsyncCallbackTestE::testAsyncCallbackIsFasterSegmentation
>  fault (core dumped) - Occasionally only
> other failing test from the suite:  
> N8activemq4test8openwire21OpenwireAdvisorysTestE::testConnectionAdvisories. : 
> assertionF  
> N8activemq4test8openwire30OpenwireEnhancedConnectionTestE::testDestinationSourceGetters.
>  : assertionF  
> N8activemq4test8openwire22OpenwireMapMessageTestE::testEmptyMapSendReceive. : 
> assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testTextMessageCompression.
>  : assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testStreamMessageCompression.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testReceiveBrowseReceive.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testQueueBrowserWith2Consumers.
>  : assertionF  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testDLQHandling. : 
> errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryReceiveNoCommit.
>  : errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryOnMessageNoCommit.
>  : errorE  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleConnections. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleSessions. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testReceiveAlreadyInQueue. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testWithZeroConsumerPrefetchWithInFlightExpiration.
>  : errorE  N8activemq4test8openwire18OpenwireSimpleTestE::tesstStreamMessage. 
> : assertionF  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testBasics. : errorE  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testTwoConnections. : 
> assertionF  
> N8activemq4test8openwire23OpenwireTransactionTestE::testSendSessionClose. : 
> errorE  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveAutoAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveClinetAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveTransacted.
>  : assertionF
> Steps to reproduce:
> 1.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-artemis/1.1.0/apache-artemis-1.1.0-bin.zip
> 2.) unzip apache-artemis-1.1.0-bin.zip
> 3.) cd apache-artemis-1.1.0/bin/
> 4.) ./artemis create broker110 --data /tmp/artemis/broker110 
> --allow-anonymous --user pematous --password pematous ../runtime/broker110
> 5.) 
> /root/A-MQ/r7.0.0/upstream/apache-artemis-1.1.0/runtime/broker110/bin/artemis-service
>  start
> 6.) cd -
> 7.) cd activemq-cpp-library-3.9.0/src/test-integration/
> 8.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-cpp/3.9.0/activemq-cpp-library-3.9.0-src.tar.gz
> 9.) tar -xf activemq-cpp-library-3.9.0-src.tar.gz
> 10.) cd activemq-cpp-library-3.9.0
> 11.) ./configure
> 12.) make check
> 13.) cd src/test-integration
> 14.) ./activemq-test-integration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-306) ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault when executed against Artemis

[Petra Svobodova (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Petra Svobodova updated ARTEMIS-306:

Attachment: terminal_transcript

Look at the terminal transcript, please.

> ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault 
> when executed against Artemis
> --
>
> Key: ARTEMIS-306
> URL: https://issues.apache.org/jira/browse/ARTEMIS-306
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, OpenWire
>Affects Versions: 1.1.0
> Environment: Machine OS: Rhel 6.7 i686 and x86_64
> Client: ActiveMQ CPP 3.9.0
>Reporter: Petra Svobodova
> Attachments: terminal_transcript
>
>
> CMS tests that leads to client segmentation fault:  
> N8activemq4test8openwire26OpenwireXATransactionsTestE::testSendReceiveTransactedBatchesSegmentation
>  fault (core dumped)  
> N8activemq4test8openwire36OpenWireCmsSendWithAsyncCallbackTestE::testAsyncCallbackIsFasterSegmentation
>  fault (core dumped) - Occasionally only
> other failing test from the suite:  
> N8activemq4test8openwire21OpenwireAdvisorysTestE::testConnectionAdvisories. : 
> assertionF  
> N8activemq4test8openwire30OpenwireEnhancedConnectionTestE::testDestinationSourceGetters.
>  : assertionF  
> N8activemq4test8openwire22OpenwireMapMessageTestE::testEmptyMapSendReceive. : 
> assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testTextMessageCompression.
>  : assertionF  
> N8activemq4test8openwire30OpenwireMessageCompressionTestE::testStreamMessageCompression.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testReceiveBrowseReceive.
>  : assertionF  
> N8activemq4test8openwire24OpenwireQueueBrowserTestE::testQueueBrowserWith2Consumers.
>  : assertionF  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testDLQHandling. : 
> errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryReceiveNoCommit.
>  : errorE  
> N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryOnMessageNoCommit.
>  : errorE  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleConnections. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleSessions. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testReceiveAlreadyInQueue. : 
> assertionF  
> N8activemq4test8openwire18OpenwireSimpleTestE::testWithZeroConsumerPrefetchWithInFlightExpiration.
>  : errorE  N8activemq4test8openwire18OpenwireSimpleTestE::tesstStreamMessage. 
> : assertionF  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testBasics. : errorE  
> N8activemq4test8openwire27OpenwireTempDestinationTestE::testTwoConnections. : 
> assertionF  
> N8activemq4test8openwire23OpenwireTransactionTestE::testSendSessionClose. : 
> errorE  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveAutoAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveClinetAck.
>  : assertionF  
> N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveTransacted.
>  : assertionF
> Steps to reproduce:
> 1.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-artemis/1.1.0/apache-artemis-1.1.0-bin.zip
> 2.) unzip apache-artemis-1.1.0-bin.zip
> 3.) cd apache-artemis-1.1.0/bin/
> 4.) ./artemis create broker110 --data /tmp/artemis/broker110 
> --allow-anonymous --user pematous --password pematous ../runtime/broker110
> 5.) 
> /root/A-MQ/r7.0.0/upstream/apache-artemis-1.1.0/runtime/broker110/bin/artemis-service
>  start
> 6.) cd -
> 7.) cd activemq-cpp-library-3.9.0/src/test-integration/
> 8.) wget 
> http://apache.miloslavbrada.cz/activemq/activemq-cpp/3.9.0/activemq-cpp-library-3.9.0-src.tar.gz
> 9.) tar -xf activemq-cpp-library-3.9.0-src.tar.gz
> 10.) cd activemq-cpp-library-3.9.0
> 11.) ./configure
> 12.) make check
> 13.) cd src/test-integration
> 14.) ./activemq-test-integration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6054) Durable subscriber cannot receive the existing messages after AMQ restarts

[Christopher L. Shannon (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018017#comment-15018017
 ] 

Christopher L. Shannon commented on AMQ-6054:
-

Are you using KahaDB? I recommend that you submit a test case to demonstrate 
this issue so we can see if there is something specific about your 
configuration that is causing this because this is a very common use case and 
there are many tests to make sure that this works properly.  One example is the 
test class DurableSubscriptionOfflineTestBase (and all children classes) which 
test various cases of durables being able to be consumed after being offline 
and after a broker restart.

The KahaDB index keeps track of durable subscriptions and and which messages 
were acked so it should be able to recover messages on restart.

> Durable subscriber cannot receive the existing messages after AMQ restarts
> --
>
> Key: AMQ-6054
> URL: https://issues.apache.org/jira/browse/AMQ-6054
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.12.1
> Environment: Redhat Linux
>Reporter: Nevin Chen
> Attachments: Web Console Snapshot.png
>
>
> *How to Reproduce*
> 1. Make a durable subscription to a topic from a JMS client.
> 2. Disconnect the JMS client.
> 3. Send a message to the subscribed topic from another JMS client.
> 4. Restart AMQ.
> 5. When the duarable re-connects to AMQ, it cannot receive the message sent 
> in step 3.
> *Cause Analysis*
> The message is saved in the persistent store successfully. However, when the 
> message is marshalled by the class MessageMarshaller, the field 
> regionDestination is not marshalled and saved to persistent store. When the 
> message is recovered from persistent store after restart, the 
> regionDestination filed of Message is empty so it is unknown which topic this 
> message belongs to.
> *Possible Cause*
> In the method 
> org.apache.activemq.broker.region.Topic.activate(ConnectionContext context, 
> final DurableTopicSubscription subscription), the 
> subscription.isRecoveryRequired() check is always false. The message cannot 
> go to the subscription.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6051) ActiveMQConnection leaking thread when resources are not well closed

[Christopher L. Shannon (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018027#comment-15018027
 ] 

Christopher L. Shannon commented on AMQ-6051:
-

This has currently only been applied to master I will backport it to 5.12.x.  I 
doubt there will be another 5.10.x release at this point.

> ActiveMQConnection leaking thread when resources are not well closed
> 
>
> Key: AMQ-6051
> URL: https://issues.apache.org/jira/browse/AMQ-6051
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Romain Manni-Bucau
>Assignee: Timothy Bish
> Fix For: 5.13.0
>
>
> ActiveMQConnection starts a session task thread but doesnt close it if 
> close() is called and the broker doesnt respond
> {code}
> try {
> if (isConnectionInfoSentToBroker) {
> // If we announced ourselves to the broker.. Try 
> to let the broker
> // know that the connection is being shutdown.
> RemoveInfo removeCommand = 
> info.createRemoveCommand();
> 
> removeCommand.setLastDeliveredSequenceId(lastDeliveredSequenceId);
> try {
> doSyncSendPacket(removeCommand, closeTimeout);
> } catch (JMSException e) {
> if (e.getCause() instanceof 
> RequestTimedOutIOException) {
> // expected
> } else {
> throw e;
> }
> }
> doAsyncSendPacket(new ShutdownInfo());
> }
> } finally {
> // ensure we clean up this connection anyway even if 
> previous send fail
> // which can happen if we lost the connection with 
> the broker
> started.set(false);
> // TODO if we move the TaskRunnerFactory to the 
> connection
> // factory
> // then we may need to call
> // factory.onConnectionClose(this);
> if (sessionTaskRunner != null) {
> sessionTaskRunner.shutdown();
> }
> closed.set(true);
> closing.set(false);
> }
> {code}
> solves it
> tested on 5.12.0 but 5.12.x has the same code so I guess it has the same issue



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQCPP-587) ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault when executed against Artemis

[Petra Svobodova (JIRA)]

Petra Svobodova created AMQCPP-587:
--

 Summary: ActiveMQ CPP (CMS) integration unit tests leads to client 
segmentation fault when executed against Artemis
 Key: AMQCPP-587
 URL: https://issues.apache.org/jira/browse/AMQCPP-587
 Project: ActiveMQ C++ Client
  Issue Type: Bug
  Components: CMS Impl
Affects Versions: 3.9.0
 Environment: Machine OS: Rhel 6.7 i686 and x86_64
Broker: Artemis 1.1.0
Reporter: Petra Svobodova
Assignee: Timothy Bish


CMS tests that leads to client segmentation fault:  
N8activemq4test8openwire26OpenwireXATransactionsTestE::testSendReceiveTransactedBatchesSegmentation
 fault (core dumped)  
N8activemq4test8openwire36OpenWireCmsSendWithAsyncCallbackTestE::testAsyncCallbackIsFasterSegmentation
 fault (core dumped) - Occasionally only

other failing test from the suite:  
N8activemq4test8openwire21OpenwireAdvisorysTestE::testConnectionAdvisories. : 
assertionF  
N8activemq4test8openwire30OpenwireEnhancedConnectionTestE::testDestinationSourceGetters.
 : assertionF  
N8activemq4test8openwire22OpenwireMapMessageTestE::testEmptyMapSendReceive. : 
assertionF  
N8activemq4test8openwire30OpenwireMessageCompressionTestE::testTextMessageCompression.
 : assertionF  
N8activemq4test8openwire30OpenwireMessageCompressionTestE::testStreamMessageCompression.
 : assertionF  
N8activemq4test8openwire24OpenwireQueueBrowserTestE::testReceiveBrowseReceive. 
: assertionF  
N8activemq4test8openwire24OpenwireQueueBrowserTestE::testQueueBrowserWith2Consumers.
 : assertionF  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testDLQHandling. : 
errorE  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryReceiveNoCommit.
 : errorE  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryOnMessageNoCommit.
 : errorE  
N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleConnections. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleSessions. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testReceiveAlreadyInQueue. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testWithZeroConsumerPrefetchWithInFlightExpiration.
 : errorE  N8activemq4test8openwire18OpenwireSimpleTestE::tesstStreamMessage. : 
assertionF  N8activemq4test8openwire27OpenwireTempDestinationTestE::testBasics. 
: errorE  
N8activemq4test8openwire27OpenwireTempDestinationTestE::testTwoConnections. : 
assertionF  
N8activemq4test8openwire23OpenwireTransactionTestE::testSendSessionClose. : 
errorE  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveAutoAck.
 : assertionF  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveClinetAck.
 : assertionF  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveTransacted.
 : assertionF

Steps to reproduce:
1.) wget 
http://apache.miloslavbrada.cz/activemq/activemq-artemis/1.1.0/apache-artemis-1.1.0-bin.zip
2.) unzip apache-artemis-1.1.0-bin.zip
3.) cd apache-artemis-1.1.0/bin/
4.) ./artemis create broker110 --data /tmp/artemis/broker110 --allow-anonymous 
--user pematous --password pematous ../runtime/broker110
5.) 
/root/A-MQ/r7.0.0/upstream/apache-artemis-1.1.0/runtime/broker110/bin/artemis-service
 start
6.) cd -
7.) cd activemq-cpp-library-3.9.0/src/test-integration/
8.) wget 
http://apache.miloslavbrada.cz/activemq/activemq-cpp/3.9.0/activemq-cpp-library-3.9.0-src.tar.gz
9.) tar -xf activemq-cpp-library-3.9.0-src.tar.gz
10.) cd activemq-cpp-library-3.9.0
11.) ./configure
12.) make check
13.) cd src/test-integration
14.) ./activemq-test-integration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ARTEMIS-306) ActiveMQ CPP (CMS) integration unit tests leads to client segmentation fault when executed against Artemis

[Petra Svobodova (JIRA)]

Petra Svobodova created ARTEMIS-306:
---

 Summary: ActiveMQ CPP (CMS) integration unit tests leads to client 
segmentation fault when executed against Artemis
 Key: ARTEMIS-306
 URL: https://issues.apache.org/jira/browse/ARTEMIS-306
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker, OpenWire
Affects Versions: 1.1.0
 Environment: Machine OS: Rhel 6.7 i686 and x86_64
Client: ActiveMQ CPP 3.9.0
Reporter: Petra Svobodova


CMS tests that leads to client segmentation fault:  
N8activemq4test8openwire26OpenwireXATransactionsTestE::testSendReceiveTransactedBatchesSegmentation
 fault (core dumped)  
N8activemq4test8openwire36OpenWireCmsSendWithAsyncCallbackTestE::testAsyncCallbackIsFasterSegmentation
 fault (core dumped) - Occasionally only

other failing test from the suite:  
N8activemq4test8openwire21OpenwireAdvisorysTestE::testConnectionAdvisories. : 
assertionF  
N8activemq4test8openwire30OpenwireEnhancedConnectionTestE::testDestinationSourceGetters.
 : assertionF  
N8activemq4test8openwire22OpenwireMapMessageTestE::testEmptyMapSendReceive. : 
assertionF  
N8activemq4test8openwire30OpenwireMessageCompressionTestE::testTextMessageCompression.
 : assertionF  
N8activemq4test8openwire30OpenwireMessageCompressionTestE::testStreamMessageCompression.
 : assertionF  
N8activemq4test8openwire24OpenwireQueueBrowserTestE::testReceiveBrowseReceive. 
: assertionF  
N8activemq4test8openwire24OpenwireQueueBrowserTestE::testQueueBrowserWith2Consumers.
 : assertionF  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testDLQHandling. : 
errorE  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryReceiveNoCommit.
 : errorE  
N8activemq4test8openwire28OpenWireRedeliveryPolicyTestE::testRepeatedRedeliveryOnMessageNoCommit.
 : errorE  
N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleConnections. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testMultipleSessions. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testReceiveAlreadyInQueue. : 
assertionF  
N8activemq4test8openwire18OpenwireSimpleTestE::testWithZeroConsumerPrefetchWithInFlightExpiration.
 : errorE  N8activemq4test8openwire18OpenwireSimpleTestE::tesstStreamMessage. : 
assertionF  N8activemq4test8openwire27OpenwireTempDestinationTestE::testBasics. 
: errorE  
N8activemq4test8openwire27OpenwireTempDestinationTestE::testTwoConnections. : 
assertionF  
N8activemq4test8openwire23OpenwireTransactionTestE::testSendSessionClose. : 
errorE  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveAutoAck.
 : assertionF  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveClinetAck.
 : assertionF  
N8activemq4test8openwire24OpenwireVirtualTopicTestE::testVirtualTopicSyncReceiveTransacted.
 : assertionF

Steps to reproduce:
1.) wget 
http://apache.miloslavbrada.cz/activemq/activemq-artemis/1.1.0/apache-artemis-1.1.0-bin.zip
2.) unzip apache-artemis-1.1.0-bin.zip
3.) cd apache-artemis-1.1.0/bin/
4.) ./artemis create broker110 --data /tmp/artemis/broker110 --allow-anonymous 
--user pematous --password pematous ../runtime/broker110
5.) 
/root/A-MQ/r7.0.0/upstream/apache-artemis-1.1.0/runtime/broker110/bin/artemis-service
 start
6.) cd -
7.) cd activemq-cpp-library-3.9.0/src/test-integration/
8.) wget 
http://apache.miloslavbrada.cz/activemq/activemq-cpp/3.9.0/activemq-cpp-library-3.9.0-src.tar.gz
9.) tar -xf activemq-cpp-library-3.9.0-src.tar.gz
10.) cd activemq-cpp-library-3.9.0
11.) ./configure
12.) make check
13.) cd src/test-integration
14.) ./activemq-test-integration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-201) Log warning if server can crash on OutOfMemory due to "misconfiguration"

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-201:
---
Fix Version/s: 1.1.1

> Log warning if server can crash on OutOfMemory due to "misconfiguration"
> 
>
> Key: ARTEMIS-201
> URL: https://issues.apache.org/jira/browse/ARTEMIS-201
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.0.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Imagine situation where server is started with 3000 destinations and 
> max-size-bytes is set to 10MB. This would mean that JVM would have to be 
> started with at least 30GB of memory to prevent OOM in case that all 
> destinations get filled up. (PAGE mode is not a solution in this case as it 
> starts once destination exceeds 10MB in memory)
> Purpose of this jira is to provide check which would print warning in case 
> that such OOM can happen. This check would be executed during start of server 
> and then with adding any destination at runtime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[Simon Lundstrom (JIRA)]

Simon Lundstrom created AMQ-6055:


 Summary: SASL PLAIN auth with AMQP doesn't take authzid into 
account
 Key: AMQ-6055
 URL: https://issues.apache.org/jira/browse/AMQ-6055
 Project: ActiveMQ
  Issue Type: Bug
  Components: AMQP, Broker, jaas
Affects Versions: 5.12.1
 Environment: # lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.3 LTS
Release:14.04
Codename:   trusty
# uname -a
Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux
Reporter: Simon Lundstrom
Priority: Blocker


SASL PLAIN authentication with AMQP doesn't take authzid into account and fails 
authentication when it's fully legal in SASL PLAIN.

See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6051) ActiveMQConnection leaking thread when resources are not well closed

[Andy Gumbrecht (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015652#comment-15015652
 ] 

Andy Gumbrecht commented on AMQ-6051:
-

Nice catch Romain,

Has this been back-ported to 5.10.x ?

> ActiveMQConnection leaking thread when resources are not well closed
> 
>
> Key: AMQ-6051
> URL: https://issues.apache.org/jira/browse/AMQ-6051
> Project: ActiveMQ
>  Issue Type: Bug
>Affects Versions: 5.12.0
>Reporter: Romain Manni-Bucau
>Assignee: Timothy Bish
> Fix For: 5.13.0
>
>
> ActiveMQConnection starts a session task thread but doesnt close it if 
> close() is called and the broker doesnt respond
> {code}
> try {
> if (isConnectionInfoSentToBroker) {
> // If we announced ourselves to the broker.. Try 
> to let the broker
> // know that the connection is being shutdown.
> RemoveInfo removeCommand = 
> info.createRemoveCommand();
> 
> removeCommand.setLastDeliveredSequenceId(lastDeliveredSequenceId);
> try {
> doSyncSendPacket(removeCommand, closeTimeout);
> } catch (JMSException e) {
> if (e.getCause() instanceof 
> RequestTimedOutIOException) {
> // expected
> } else {
> throw e;
> }
> }
> doAsyncSendPacket(new ShutdownInfo());
> }
> } finally {
> // ensure we clean up this connection anyway even if 
> previous send fail
> // which can happen if we lost the connection with 
> the broker
> started.set(false);
> // TODO if we move the TaskRunnerFactory to the 
> connection
> // factory
> // then we may need to call
> // factory.onConnectionClose(this);
> if (sessionTaskRunner != null) {
> sessionTaskRunner.shutdown();
> }
> closed.set(true);
> closing.set(false);
> }
> {code}
> solves it
> tested on 5.12.0 but 5.12.x has the same code so I guess it has the same issue



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-226) Fix typo in Netty TransportConstants

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-226:
---
Fix Version/s: 1.1.1

> Fix typo in Netty TransportConstants
> 
>
> Key: ARTEMIS-226
> URL: https://issues.apache.org/jira/browse/ARTEMIS-226
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Value of  HTTP_UPGRADE_ENDPOINT_PROP_NAME is "httpPpgradeEndpoint".
> It should be fixed to "httpUpgradeEndpoint"
> https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/TransportConstants.java#L44



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-226) Fix typo in Netty TransportConstants

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-226:
--

Assignee: Justin Bertram

> Fix typo in Netty TransportConstants
> 
>
> Key: ARTEMIS-226
> URL: https://issues.apache.org/jira/browse/ARTEMIS-226
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Value of  HTTP_UPGRADE_ENDPOINT_PROP_NAME is "httpPpgradeEndpoint".
> It should be fixed to "httpUpgradeEndpoint"
> https://github.com/apache/activemq-artemis/blob/master/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/TransportConstants.java#L44



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARTEMIS-221) MDB endpoionts are not deactivated

[Andy Taylor (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Taylor resolved ARTEMIS-221.
-
Resolution: Fixed

yes ive resolved it

> MDB endpoionts are not deactivated
> --
>
> Key: ARTEMIS-221
> URL: https://issues.apache.org/jira/browse/ARTEMIS-221
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.0.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> Sometimes when an endpoint is deactivated it still carries on consuming 
> messages. This happens when multiple endpoints are activated and is caused 
> becasue equals/hashcode arent implemented on ActiveMQActivationSpec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pablo Lozano updated AMQ-6052:
--
Attachment: AMQ_6052.patch

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
> at 
> 

[jira] [Commented] (ARTEMIS-201) Log warning if server can crash on OutOfMemory due to "misconfiguration"

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018134#comment-15018134
 ] 

ASF GitHub Bot commented on ARTEMIS-201:


GitHub user jbertram opened a pull request:

https://github.com/apache/activemq-artemis/pull/245

ARTEMIS-201 warn of potential OOME



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-201

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/activemq-artemis/pull/245.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 #245


commit f09355bfdad220a300eb46f4474772c57368c30a
Author: jbertram 
Date:   2015-11-20T02:41:31Z

ARTEMIS-201 warn of potential OOME




> Log warning if server can crash on OutOfMemory due to "misconfiguration"
> 
>
> Key: ARTEMIS-201
> URL: https://issues.apache.org/jira/browse/ARTEMIS-201
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.0.0
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Imagine situation where server is started with 3000 destinations and 
> max-size-bytes is set to 10MB. This would mean that JVM would have to be 
> started with at least 30GB of memory to prevent OOM in case that all 
> destinations get filled up. (PAGE mode is not a solution in this case as it 
> starts once destination exceeds 10MB in memory)
> Purpose of this jira is to provide check which would print warning in case 
> that such OOM can happen. This check would be executed during start of server 
> and then with adding any destination at runtime.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-221) MDB endpoionts are not deactivated

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018203#comment-15018203
 ] 

Justin Bertram commented on ARTEMIS-221:


This looks resolved to me.  Can you confirm, [~andytaylor]?

> MDB endpoionts are not deactivated
> --
>
> Key: ARTEMIS-221
> URL: https://issues.apache.org/jira/browse/ARTEMIS-221
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.0.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> Sometimes when an endpoint is deactivated it still carries on consuming 
> messages. This happens when multiple endpoints are activated and is caused 
> becasue equals/hashcode arent implemented on ActiveMQActivationSpec



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish updated AMQ-6055:
--
Fix Version/s: 5.13.0

> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-246) Warn if the destination lookup for the MDB activation fails

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018398#comment-15018398
 ] 

Justin Bertram commented on ARTEMIS-246:


I agree that it might not be a good idea to have this silent fallback behavior 
when the JNDI look-up fails.  This was added way back in April 2009 (see 
06d01a9c0f5b89994be900c73318dce95ce6daa2 in the HornetQ git repo).  
Furthermore, this used to be logged at INFO level, but was change to DEBUG in 
2012 (see 55f6e60bbcb7118b68653fe9e6d136393eefef1e in the HornetQ git repo).  

I don't mind changing the logging to WARN, but I wonder if we should just let 
the JNDI lookup fail without creating the destination.  In my opinion, a JNDI 
lookup failure indicates a bad configuration somewhere which we shouldn't try 
to work around.  Do you have any thoughts on this, [~clebertsuconic]?


> Warn if the destination lookup for the MDB activation fails
> ---
>
> Key: ARTEMIS-246
> URL: https://issues.apache.org/jira/browse/ARTEMIS-246
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Jeff Mesnil
>
> in Artemis RA, the destination is by default looked up by JNDI using the 
> destinationLookup (or destination) activation config properties.
> If the lookup fails, it will automatically create a JMS destination based on 
> the destination name.
> There is a debug log in that case: "Unable to retrieve... etc." but I think 
> this should be upgraded to a WARN log as it is a configuration issue that the 
> user must be aware of.
> I'm not sure whether this is even a good idea to have this fallback when the 
> JNDI lookup fails.
> Creating a client-side JMS destination can also be achieved by setting the 
> destination activation config property *and* setting the useJNDI prop to 
> false.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-246) Warn if the destination lookup for the MDB activation fails

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-246:
--

Assignee: Justin Bertram

> Warn if the destination lookup for the MDB activation fails
> ---
>
> Key: ARTEMIS-246
> URL: https://issues.apache.org/jira/browse/ARTEMIS-246
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
>
> in Artemis RA, the destination is by default looked up by JNDI using the 
> destinationLookup (or destination) activation config properties.
> If the lookup fails, it will automatically create a JMS destination based on 
> the destination name.
> There is a debug log in that case: "Unable to retrieve... etc." but I think 
> this should be upgraded to a WARN log as it is a configuration issue that the 
> user must be aware of.
> I'm not sure whether this is even a good idea to have this fallback when the 
> JNDI lookup fails.
> Creating a client-side JMS destination can also be achieved by setting the 
> destination activation config property *and* setting the useJNDI prop to 
> false.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018499#comment-15018499
 ] 

Pablo Lozano edited comment on AMQ-6052 at 11/20/15 6:45 PM:
-

I have included a patch for this issue. From the way that it is done it removes 
the need to synchronize operations which is a good thing.


was (Author: altaflux):
I have included a patch for this issue.

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> 

[jira] [Commented] (AMQ-5026) Replicated LevelDB Store getting EOF exception

[Alex Paransky (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018408#comment-15018408
 ] 

Alex Paransky commented on AMQ-5026:


I am having a similar problem with a very similar configuration:

3 servers, 1 master/2 slave configuration, seeing this exception with 5.10.0:

{code}
2015-11-20 15:57:34,832 | INFO  | Stopping BrokerService[localhost] due to 
exception, java.io.EOFException | 
org.apache.activemq.util.DefaultIOExceptionHandler | LevelDB IOException 
handler.
java.io.EOFException
at 
org.apache.activemq.util.DataByteArrayInputStream.readOrIOException(DataByteArrayInputStream.java:127)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.util.DataByteArrayInputStream.readBoolean(DataByteArrayInputStream.java:189)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.v6.BaseDataStreamMarshaller.looseUnmarshalByteSequence(BaseDataStreamMarshaller.java:637)[activemq-openwire-legacy-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.v6.MessageMarshaller.looseUnmarshal(MessageMarshaller.java:229)[activemq-openwire-legacy-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.v6.ActiveMQMessageMarshaller.looseUnmarshal(ActiveMQMessageMarshaller.java:101)[activemq-openwire-legacy-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.v6.ActiveMQTextMessageMarshaller.looseUnmarshal(ActiveMQTextMessageMarshaller.java:101)[activemq-openwire-legacy-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.OpenWireFormat.doUnmarshal(OpenWireFormat.java:356)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:193)[activemq-client-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.decodeMessage(LevelDBClient.scala:1336)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$getMessage$1.apply(LevelDBClient.scala:1327)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$getMessage$1.apply(LevelDBClient.scala:1327)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at scala.Option.map(Option.scala:145)[scala-library-2.11.0.jar:]
at 
org.apache.activemq.leveldb.LevelDBClient.getMessage(LevelDBClient.scala:1327)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1262)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$queueCursor$1.apply(LevelDBClient.scala:1259)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1347)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1$$anonfun$apply$mcV$sp$12.apply(LevelDBClient.scala:1346)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.check$4(LevelDBClient.scala:323)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$RichDB.cursorRange(LevelDBClient.scala:325)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply$mcV$sp(LevelDBClient.scala:1346)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1346)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$collectionCursor$1.apply(LevelDBClient.scala:1346)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.usingIndex(LevelDBClient.scala:1026)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient$$anonfun$might_fail_using_index$1.apply(LevelDBClient.scala:1032)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail(LevelDBClient.scala:549)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.might_fail_using_index(LevelDBClient.scala:1032)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.collectionCursor(LevelDBClient.scala:1345)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBClient.queueCursor(LevelDBClient.scala:1259)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.DBManager.cursorMessages(DBManager.scala:735)[activemq-leveldb-store-5.10.0.jar:5.10.0]
at 
org.apache.activemq.leveldb.LevelDBStore$LevelDBMessageStore.recoverNextMessages(LevelDBStore.scala:762)[activemq-leveldb-store-5.10.0.jar:5.10.0]
  

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018426#comment-15018426
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit ce5628a389b5491975fda0493ab9073cca6cb87e in activemq's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ce5628a ]

AMQ-6055: uptest test client and add [currently-ignored] test to demonstrate 
the issue


> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018499#comment-15018499
 ] 

Pablo Lozano commented on AMQ-6052:
---

I have included a patch for this issue.

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
> 

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018452#comment-15018452
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit d7e4c6d96f0e5b26d4b392e6b36595ee644fb9a2 in activemq's branch 
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=d7e4c6d ]

AMQ-6055: fix for earlier change to plain response encoding


> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (AMQ-5712) Broker can deadlock when using queues while producers wait on disk space

[Christopher L. Shannon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher L. Shannon reassigned AMQ-5712:
---

Assignee: Christopher L. Shannon

> Broker can deadlock when using queues while producers wait on disk space
> 
>
> Key: AMQ-5712
> URL: https://issues.apache.org/jira/browse/AMQ-5712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Attachments: queue-cursor.patch
>
>
> I am experiencing a deadlock when using a Queue with non-persistent messages. 
>  The queue has a cursor high memory water mark set (right now at 70%).  When 
> a producer is producing messages quickly to the queue and that limit gets 
> hit, the broker can deadlock.   I have tried setting producerWindowSize and 
> alwaysSyncSend which did not seem to help. When the broker hits that limit, I 
> am unable to do things like purge the queue.  Consumers can also deadlock as 
> well. 
> Note that this appears to be the same issue as described in this ticket here: 
> AMQ-2475 .  The difference is that I am using a Queue and not a Topic and the 
> fix for this appears to only have been for Topics.
> The problem appears to be in the Queue class on line 1852 inside the 
> {{cursorAdd}} method.  The method being called is {{return 
> messages.addMessageLast(msg);}} which will block indefinitely if there is no 
> space available, which in turn ties up the {{messagesLock}} from being used 
> by any other threads.  We have seen a deadlock where consumers can't consume 
> because they are waiting on this lock.   It looks like in AMQ-2475 part of 
> the fix was to replace {{messages.addMessageLast(msg)}} with 
> {{messages.tryAddMessageLast(msg, 10)}}.  I also noticed that not all of the 
> message cursors support {{tryAddMessageLast}}, which could be a problem.  
> {{FilePendingMessageCursor}} implements it but the rest of the cursors 
> (notably {{StoreQueueCursor}}) simply delegate back to {{addMessageLast}} in 
> the parent class.  So part of this fix may require implementing 
> {{tryAddMessageLast}} across more cursors.
> Here is part of the thread dump showing the stuck producer:
> {code}
> "ActiveMQ Transport: ssl:///192.168.3.142:38589" daemon prio=10 
> tid=0x7fb46c006000 nid=0x3b1a runnable [0x7fb4b8a0d000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0xcfb13cd0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2176)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:103)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:90)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:80)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:235)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.addMessageLast(FilePendingMessageCursor.java:207)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.addMessageLast(StoreQueueCursor.java:97)
> - locked <0xd1f20908> (a 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018626#comment-15018626
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit b5dd0a16f4197cfab086b3139892a73b27c8ac74 in activemq's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=b5dd0a1 ]

https://issues.apache.org/jira/browse/AMQ-6055

Account for Authzid in SASL PLAIN mechanism and provide a means to fail
the authorization if the challenge response is invalid.  Update the
client to properly exclude sasl mechanism that don't apply to it's
configured credentials such as using only ANONYMOUS when no user or
password is set.  

> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ARTEMIS-250) Scale down fails with ActiveMQSecurityException

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-250:
---
Fix Version/s: 1.1.1

> Scale down fails with ActiveMQSecurityException
> ---
>
> Key: ARTEMIS-250
> URL: https://issues.apache.org/jira/browse/ARTEMIS-250
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Brandon Breuil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> Scale down is throwing a security exception. It appears that the connection 
> used to scale down is not authenticating properly with the target server when 
> security is enabled. I've verified that scale down works properly when 
> security is disabled.
> I'm using a colocated HA policy with replication.
> 16:34:35,783 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: 
> ActiveMQSecurityException[errorType=SECURITY_EXCEPTION message=AMQ119031: 
> Unable to validate user: null]
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:358)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:283)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQClientProtocolManager.createSessionContext(ActiveMQClientProtocolManager.java:231)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionChannel(ClientSessionFactoryImpl.java:1235)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:617)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:314)
>  [artemis-core-client-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ScaleDownHandler.scaleDownMessages(ScaleDownHandler.java:106)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ScaleDownHandler.scaleDown(ScaleDownHandler.java:94)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.BackupRecoveryJournalLoader.postLoad(BackupRecoveryJournalLoader.java:94)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.loadMessageJournal(JournalStorageManager.java:1573)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:1641)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1535)
>  [artemis-server-1.1.0.jar:1.1.0]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:245)
>  [artemis-server-1.1.0.jar:1.1.0]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018701#comment-15018701
 ] 

Pablo Lozano commented on AMQ-6052:
---

No problem, 
Let me work out a test and attach it.

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
> 

[jira] [Updated] (AMQ-6056) Refactor non-persistent limits in terms of the temporary store usage

[Christopher L. Shannon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher L. Shannon updated AMQ-6056:

Summary: Refactor non-persistent limits in terms of the temporary store 
usage  (was: Refactor non-persistent limits in terms of the temporary store)

> Refactor non-persistent limits in terms of the temporary store usage
> 
>
> Key: AMQ-6056
> URL: https://issues.apache.org/jira/browse/AMQ-6056
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.14.0
>Reporter: Christopher L. Shannon
>
> Refactor the limits used for tracking of non-persistent messages so that the 
> limit of the temporary store usage is taken into account instead of just the 
> memory usage limit as the messages in memory can be higher than available 
> temporary storage.  This scenario could cause deadlocks such as the scenario 
> in AMQ-5712.  
> The fix in AMQ-5712 works around this by using a timeout when trying to add a 
> message to a Queue to prevent a deadlock but this is just a work around and 
> the underlying cause should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (AMQ-6056) Refactor non-persistent limits in terms of the temporary store

[Christopher L. Shannon (JIRA)]

Christopher L. Shannon created AMQ-6056:
---

 Summary: Refactor non-persistent limits in terms of the temporary 
store
 Key: AMQ-6056
 URL: https://issues.apache.org/jira/browse/AMQ-6056
 Project: ActiveMQ
  Issue Type: Improvement
  Components: Broker
Affects Versions: 5.14.0
Reporter: Christopher L. Shannon


Refactor the limits used for tracking of non-persistent messages so that the 
limit of the temporary store usage is taken into account instead of just the 
memory usage limit as the messages in memory can be higher than available 
temporary storage.  This scenario could cause deadlocks such as the scenario in 
AMQ-5712.  

The fix in AMQ-5712 works around this by using a timeout when trying to add a 
message to a Queue to prevent a deadlock but this is just a work around and the 
underlying cause should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5712) Broker can deadlock when using queues while producers wait on disk space

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018770#comment-15018770
 ] 

ASF subversion and git services commented on AMQ-5712:
--

Commit cc6213ebf25a129b278a2ff0d7c32c25edd71eaa in activemq's branch 
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=cc6213e ]

https://issues.apache.org/jira/browse/AMQ-5712

Switching addMessageLast to tryAddMessageLast when messages are added
to a Queue pending cursor to allow a potential deadlock to be
avoided. There is more work to be done here but this will at least
prevent a deadlock from occurring.

Fix and test based off of a patch created by Timothy Bish.


> Broker can deadlock when using queues while producers wait on disk space
> 
>
> Key: AMQ-5712
> URL: https://issues.apache.org/jira/browse/AMQ-5712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Attachments: queue-cursor.patch
>
>
> I am experiencing a deadlock when using a Queue with non-persistent messages. 
>  The queue has a cursor high memory water mark set (right now at 70%).  When 
> a producer is producing messages quickly to the queue and that limit gets 
> hit, the broker can deadlock.   I have tried setting producerWindowSize and 
> alwaysSyncSend which did not seem to help. When the broker hits that limit, I 
> am unable to do things like purge the queue.  Consumers can also deadlock as 
> well. 
> Note that this appears to be the same issue as described in this ticket here: 
> AMQ-2475 .  The difference is that I am using a Queue and not a Topic and the 
> fix for this appears to only have been for Topics.
> The problem appears to be in the Queue class on line 1852 inside the 
> {{cursorAdd}} method.  The method being called is {{return 
> messages.addMessageLast(msg);}} which will block indefinitely if there is no 
> space available, which in turn ties up the {{messagesLock}} from being used 
> by any other threads.  We have seen a deadlock where consumers can't consume 
> because they are waiting on this lock.   It looks like in AMQ-2475 part of 
> the fix was to replace {{messages.addMessageLast(msg)}} with 
> {{messages.tryAddMessageLast(msg, 10)}}.  I also noticed that not all of the 
> message cursors support {{tryAddMessageLast}}, which could be a problem.  
> {{FilePendingMessageCursor}} implements it but the rest of the cursors 
> (notably {{StoreQueueCursor}}) simply delegate back to {{addMessageLast}} in 
> the parent class.  So part of this fix may require implementing 
> {{tryAddMessageLast}} across more cursors.
> Here is part of the thread dump showing the stuck producer:
> {code}
> "ActiveMQ Transport: ssl:///192.168.3.142:38589" daemon prio=10 
> tid=0x7fb46c006000 nid=0x3b1a runnable [0x7fb4b8a0d000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0xcfb13cd0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2176)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:103)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:90)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:80)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:235)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.addMessageLast(FilePendingMessageCursor.java:207)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.addMessageLast(StoreQueueCursor.java:97)
> - locked <0xd1f20908> (a 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-5712) Broker can deadlock when using queues while producers wait on disk space

[Christopher L. Shannon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher L. Shannon resolved AMQ-5712.
-
   Resolution: Fixed
Fix Version/s: 5.13.0

This has been fixed by applying the patch submitted here.  I have created a new 
ticket to track progress for a better solution in the future AMQ-6056

> Broker can deadlock when using queues while producers wait on disk space
> 
>
> Key: AMQ-5712
> URL: https://issues.apache.org/jira/browse/AMQ-5712
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.11.1
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
> Fix For: 5.13.0
>
> Attachments: queue-cursor.patch
>
>
> I am experiencing a deadlock when using a Queue with non-persistent messages. 
>  The queue has a cursor high memory water mark set (right now at 70%).  When 
> a producer is producing messages quickly to the queue and that limit gets 
> hit, the broker can deadlock.   I have tried setting producerWindowSize and 
> alwaysSyncSend which did not seem to help. When the broker hits that limit, I 
> am unable to do things like purge the queue.  Consumers can also deadlock as 
> well. 
> Note that this appears to be the same issue as described in this ticket here: 
> AMQ-2475 .  The difference is that I am using a Queue and not a Topic and the 
> fix for this appears to only have been for Topics.
> The problem appears to be in the Queue class on line 1852 inside the 
> {{cursorAdd}} method.  The method being called is {{return 
> messages.addMessageLast(msg);}} which will block indefinitely if there is no 
> space available, which in turn ties up the {{messagesLock}} from being used 
> by any other threads.  We have seen a deadlock where consumers can't consume 
> because they are waiting on this lock.   It looks like in AMQ-2475 part of 
> the fix was to replace {{messages.addMessageLast(msg)}} with 
> {{messages.tryAddMessageLast(msg, 10)}}.  I also noticed that not all of the 
> message cursors support {{tryAddMessageLast}}, which could be a problem.  
> {{FilePendingMessageCursor}} implements it but the rest of the cursors 
> (notably {{StoreQueueCursor}}) simply delegate back to {{addMessageLast}} in 
> the parent class.  So part of this fix may require implementing 
> {{tryAddMessageLast}} across more cursors.
> Here is part of the thread dump showing the stuck producer:
> {code}
> "ActiveMQ Transport: ssl:///192.168.3.142:38589" daemon prio=10 
> tid=0x7fb46c006000 nid=0x3b1a runnable [0x7fb4b8a0d000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for  <0xcfb13cd0> (a 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at 
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2176)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:103)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:90)
> at org.apache.activemq.usage.Usage.waitForSpace(Usage.java:80)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.tryAddMessageLast(FilePendingMessageCursor.java:235)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor.addMessageLast(FilePendingMessageCursor.java:207)
> - locked <0xd2015ee0> (a 
> org.apache.activemq.broker.region.cursors.FilePendingMessageCursor)
> at 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor.addMessageLast(StoreQueueCursor.java:97)
> - locked <0xd1f20908> (a 
> org.apache.activemq.broker.region.cursors.StoreQueueCursor)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6056) Refactor non-persistent limits in terms of the temporary store usage

[Christopher L. Shannon (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher L. Shannon updated AMQ-6056:

Affects Version/s: (was: 5.14.0)
   5.12.1
Fix Version/s: 5.14.0

> Refactor non-persistent limits in terms of the temporary store usage
> 
>
> Key: AMQ-6056
> URL: https://issues.apache.org/jira/browse/AMQ-6056
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 5.12.1
>Reporter: Christopher L. Shannon
> Fix For: 5.14.0
>
>
> Refactor the limits used for tracking of non-persistent messages so that the 
> limit of the temporary store usage is taken into account instead of just the 
> memory usage limit as the messages in memory can be higher than available 
> temporary storage.  This scenario could cause deadlocks such as the scenario 
> in AMQ-5712.  
> The fix in AMQ-5712 works around this by using a timeout when trying to add a 
> message to a Queue to prevent a deadlock but this is just a work around and 
> the underlying cause should be fixed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018820#comment-15018820
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit 451344486be8d82a2a9cde093fedf0737104ab83 in activemq's branch 
refs/heads/activemq-5.12.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=4513444 ]

https://issues.apache.org/jira/browse/AMQ-6055

Account for Authzid in SASL PLAIN mechanism and provide a means to fail
the authorization if the challenge response is invalid.  Update the
client to properly exclude sasl mechanism that don't apply to it's
configured credentials such as using only ANONYMOUS when no user or
password is set.
(cherry picked from commit b5dd0a16f4197cfab086b3139892a73b27c8ac74)


> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0, 5.12.2
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (AMQ-6042) In ActiveMQMessageConsumer, always set rollback cause

[Timothy Bish (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Timothy Bish resolved AMQ-6042.
---
   Resolution: Fixed
Fix Version/s: 5.13.0

Fix and test added with thanks.

> In ActiveMQMessageConsumer, always set rollback cause
> -
>
> Key: AMQ-6042
> URL: https://issues.apache.org/jira/browse/AMQ-6042
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Reporter: Martin Lichtin
> Fix For: 5.13.0
>
> Attachments: MessageListenerRedeliveryTest.java
>
>
> In ActiveMQMessageConsumer, currently the rollback cause is only set for the 
> case auto- or individual-acks. However, it should also be set for the other 
> cases, so that in the rollback() method it can be picked up when creating the 
> poison ack.
> {code}
> if (isAutoAcknowledgeBatch() || isAutoAcknowledgeEach() || 
> session.isIndividualAcknowledge()) {
> // schedual redelivery and possible dlq processing
> md.setRollbackCause(e);
> rollback();
> } else {
> // Transacted or Client ack: Deliver the next message.
> afterMessageIsConsumed(md, false);
> }
> {code}
> I'd suggest to move md.setRollbackCause(e); to before the if().



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018818#comment-15018818
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit e5c46df48c153129b6085301018ccda620d15ebc in activemq's branch 
refs/heads/activemq-5.12.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=e5c46df ]

AMQ-6055: uptest test client and add [currently-ignored] test to demonstrate 
the issue

(cherry picked from commit ce5628a389b5491975fda0493ab9073cca6cb87e)


> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0, 5.12.2
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6055) SASL PLAIN auth with AMQP doesn't take authzid into account

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018819#comment-15018819
 ] 

ASF subversion and git services commented on AMQ-6055:
--

Commit c8994b1d2eef47f68f265d06c3572624e23ef2bc in activemq's branch 
refs/heads/activemq-5.12.x from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=c8994b1 ]

AMQ-6055: fix for earlier change to plain response encoding

(cherry picked from commit d7e4c6d96f0e5b26d4b392e6b36595ee644fb9a2)


> SASL PLAIN auth with AMQP doesn't take authzid into account
> ---
>
> Key: AMQ-6055
> URL: https://issues.apache.org/jira/browse/AMQ-6055
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: AMQP, Broker, jaas
>Affects Versions: 5.12.1
> Environment: # lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:Ubuntu 14.04.3 LTS
> Release:14.04
> Codename:   trusty
> # uname -a
> Linux esb-test-mq01 3.13.0-67-generic #110-Ubuntu SMP Fri Oct 23 13:24:41 UTC 
> 2015 x86_64 x86_64 x86_64 GNU/Linux
>Reporter: Simon Lundstrom
>Priority: Blocker
> Fix For: 5.13.0, 5.12.2
>
>
> SASL PLAIN authentication with AMQP doesn't take authzid into account and 
> fails authentication when it's fully legal in SASL PLAIN.
> See [PROTON-1055] for a more detailed description including debug logs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARTEMIS-261) Allow certificate based JAAS security

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-261.

   Resolution: Fixed
Fix Version/s: 1.1.1

> Allow certificate based JAAS security
> -
>
> Key: ARTEMIS-261
> URL: https://issues.apache.org/jira/browse/ARTEMIS-261
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.1.1
>Reporter: Stephen Lewis
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> ARTEMIS-74 imported ActiveMQ 5 JAAS. However, this doesn't allow certificate 
> based authentication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-295) Reword log messages that use the word "yet".

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018985#comment-15018985
 ] 

Justin Bertram commented on ARTEMIS-295:


This looks resolved to me.  Can you confirm, [~martyntaylor]]?

> Reword log messages that use the word "yet".
> 
>
> Key: ARTEMIS-295
> URL: https://issues.apache.org/jira/browse/ARTEMIS-295
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>
> Some of our log messages are poorly worded.  Messages that include the word 
> yet.  For example: 
> "The JMS Server has not started yet" are misleading as they imply that some 
> is scheduled to happen in the future. e.g. the JMS Server is in the process 
> of starting... is is scheduled to start.
> However, this can be thrown at shutdown.  These log messages are misleading 
> and should be changed to remove "yet".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-294) Make ServiceUtils loads its services within doPrivileged block

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-294:
--

Assignee: Justin Bertram

> Make ServiceUtils loads its services within doPrivileged block
> --
>
> Key: ARTEMIS-294
> URL: https://issues.apache.org/jira/browse/ARTEMIS-294
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> We have tests that fails when the JVM is running a Security Manager.
> {noformat}
> 1) IJ000604: Throwable while attempting to get a new connection: null: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.io.FilePermission" 
> "/opt/buildAgent/work/6da23a4ee9951677/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/wildfly-messaging-activemq-10.0.0.CR5-SNAPSHOT.jar"
>  "read")" in code source "(vfs:/content/DefaultJMSConnectionFactoryTest.jar 
> )" of "null")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.(ZipFile.java:210)
> at java.util.zip.ZipFile.(ZipFile.java:149)
> at java.util.jar.JarFile.(JarFile.java:166)
> at java.util.jar.JarFile.(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1038)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at 
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.setActiveMQXAResourceWrapperFactory(ServiceUtils.java:72)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.getActiveMQXAResourceWrapperFactory(ServiceUtils.java:40)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.wrapXAResource(ServiceUtils.java:46)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.getXAResource(ActiveMQRAManagedConnection.java:480)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.createConnectionListener(TxConnectionManagerImpl.java:715)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1345)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:501)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:717)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:614)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:603)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:761)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
>...
> {noformat}
> After debugging, the issue is in the RA's ServiceUtils that loads its 
> 

[jira] [Resolved] (ARTEMIS-294) Make ServiceUtils loads its services within doPrivileged block

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-294.

Resolution: Fixed

> Make ServiceUtils loads its services within doPrivileged block
> --
>
> Key: ARTEMIS-294
> URL: https://issues.apache.org/jira/browse/ARTEMIS-294
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> We have tests that fails when the JVM is running a Security Manager.
> {noformat}
> 1) IJ000604: Throwable while attempting to get a new connection: null: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.io.FilePermission" 
> "/opt/buildAgent/work/6da23a4ee9951677/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/wildfly-messaging-activemq-10.0.0.CR5-SNAPSHOT.jar"
>  "read")" in code source "(vfs:/content/DefaultJMSConnectionFactoryTest.jar 
> )" of "null")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.(ZipFile.java:210)
> at java.util.zip.ZipFile.(ZipFile.java:149)
> at java.util.jar.JarFile.(JarFile.java:166)
> at java.util.jar.JarFile.(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1038)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at 
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.setActiveMQXAResourceWrapperFactory(ServiceUtils.java:72)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.getActiveMQXAResourceWrapperFactory(ServiceUtils.java:40)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.wrapXAResource(ServiceUtils.java:46)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.getXAResource(ActiveMQRAManagedConnection.java:480)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.createConnectionListener(TxConnectionManagerImpl.java:715)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1345)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:501)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:717)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:614)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:603)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:761)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
>...
> {noformat}
> After debugging, the issue is in the RA's ServiceUtils that loads its 
> services outside a 

[jira] [Updated] (ARTEMIS-294) Make ServiceUtils loads its services within doPrivileged block

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram updated ARTEMIS-294:
---
Fix Version/s: 1.1.1

> Make ServiceUtils loads its services within doPrivileged block
> --
>
> Key: ARTEMIS-294
> URL: https://issues.apache.org/jira/browse/ARTEMIS-294
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 1.1.1
>
>
> We have tests that fails when the JVM is running a Security Manager.
> {noformat}
> 1) IJ000604: Throwable while attempting to get a new connection: null: 
> java.security.AccessControlException: WFSM01: Permission check failed 
> (permission "("java.io.FilePermission" 
> "/opt/buildAgent/work/6da23a4ee9951677/dist/target/wildfly-10.0.0.CR5-SNAPSHOT/modules/system/layers/base/org/wildfly/extension/messaging-activemq/main/wildfly-messaging-activemq-10.0.0.CR5-SNAPSHOT.jar"
>  "read")" in code source "(vfs:/content/DefaultJMSConnectionFactoryTest.jar 
> )" of "null")
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at 
> org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:377)
> at java.util.zip.ZipFile.(ZipFile.java:210)
> at java.util.zip.ZipFile.(ZipFile.java:149)
> at java.util.jar.JarFile.(JarFile.java:166)
> at java.util.jar.JarFile.(JarFile.java:103)
> at sun.net.www.protocol.jar.URLJarFile.(URLJarFile.java:93)
> at sun.net.www.protocol.jar.URLJarFile.getJarFile(URLJarFile.java:69)
> at sun.net.www.protocol.jar.JarFileFactory.get(JarFileFactory.java:99)
> at 
> sun.net.www.protocol.jar.JarURLConnection.connect(JarURLConnection.java:122)
> at 
> sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:150)
> at java.net.URL.openStream(URL.java:1038)
> at java.util.ServiceLoader.parse(ServiceLoader.java:304)
> at java.util.ServiceLoader.access$200(ServiceLoader.java:185)
> at 
> java.util.ServiceLoader$LazyIterator.hasNextService(ServiceLoader.java:357)
> at java.util.ServiceLoader$LazyIterator.access$600(ServiceLoader.java:323)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:396)
> at java.util.ServiceLoader$LazyIterator$1.run(ServiceLoader.java:395)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.util.ServiceLoader$LazyIterator.hasNext(ServiceLoader.java:398)
> at java.util.ServiceLoader$1.hasNext(ServiceLoader.java:474)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.setActiveMQXAResourceWrapperFactory(ServiceUtils.java:72)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.getActiveMQXAResourceWrapperFactory(ServiceUtils.java:40)
> at 
> org.apache.activemq.artemis.service.extensions.ServiceUtils.wrapXAResource(ServiceUtils.java:46)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRAManagedConnection.getXAResource(ActiveMQRAManagedConnection.java:480)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.createConnectionListener(TxConnectionManagerImpl.java:715)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.createConnectionEventListener(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:1345)
> at 
> org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreConcurrentLinkedDequeManagedConnectionPool.getConnection(SemaphoreConcurrentLinkedDequeManagedConnectionPool.java:501)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getTransactionNewConnection(AbstractPool.java:717)
> at 
> org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:614)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:603)
> at 
> org.jboss.jca.core.connectionmanager.tx.TxConnectionManagerImpl.getManagedConnection(TxConnectionManagerImpl.java:430)
> at 
> org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:761)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.allocateConnection(ActiveMQRASessionFactoryImpl.java:853)
> at 
> org.apache.activemq.artemis.ra.ActiveMQRASessionFactoryImpl.createSession(ActiveMQRASessionFactoryImpl.java:520)
>...
> {noformat}
> After debugging, the issue is in the RA's ServiceUtils that loads its 
> services outside 

[jira] [Commented] (ARTEMIS-297) Handle exceptions during server stop

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018988#comment-15018988
 ] 

Justin Bertram commented on ARTEMIS-297:


This looks resolved to me.  Can you confirm, [~martyntaylor]]?

> Handle exceptions during server stop
> 
>
> Key: ARTEMIS-297
> URL: https://issues.apache.org/jira/browse/ARTEMIS-297
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>
> The server stop method is quite brittle.  If any component throws an 
> exception during shutdown, the exception is thrown and the method exits.  
> Instead the stop method on the server should be able to handle such 
> exceptions and continue shutting down all components and eventually stop the 
> ExecutorServices.  Failure to do so can lead to leaking threads.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-296) Do not print stack trace on BridgeDisconnect

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018987#comment-15018987
 ] 

Justin Bertram commented on ARTEMIS-296:


This looks resolved to me.  Can you confirm, [~martyntaylor]]?

> Do not print stack trace on BridgeDisconnect
> 
>
> Key: ARTEMIS-296
> URL: https://issues.apache.org/jira/browse/ARTEMIS-296
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>
> A bridge disconnect can happen for many reasons, network down, server down, 
> restart etc...  We currently log a WARN message to indicate this has 
> happened.  However, the WARN message includes a stack trace which can look 
> like something has failed or an error has occurred.
> We should remove the stack trace from this WARN message



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-281) JGroups channel Broadcast Endpoint reference counting broken

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018998#comment-15018998
 ] 

Justin Bertram commented on ARTEMIS-281:


This looks resolved to me.  Can you confirm, [~andytaylor]?

> JGroups channel Broadcast Endpoint reference counting broken
> 
>
> Key: ARTEMIS-281
> URL: https://issues.apache.org/jira/browse/ARTEMIS-281
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> this is because JGroupsChannelBroadcastEndpoint does not do anything when 
> closed so if a new channel is created with the same channel name the old one 
> is returned which may be closed



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (ARTEMIS-303) listDurableSubscriptionsAsJson fails if there is a durable subscription on a JMS topic

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-303:
--

Assignee: Justin Bertram

> listDurableSubscriptionsAsJson fails if there is a durable subscription on a 
> JMS topic
> --
>
> Key: ARTEMIS-303
> URL: https://issues.apache.org/jira/browse/ARTEMIS-303
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.1.0
> Environment: WildFly 10.0.0.CR2
>Reporter: Richard DiCroce
>Assignee: Justin Bertram
>
> I have some durable subscriptions on a JMS topic. When I invoke the 
> listDurableSubscriptionsAsJson JMX operation, I get this error:
> {code}
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) javax.jms.JMSRuntimeException: 
> Invalid message queue name: ASIDE-FullStatus
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at 
> org.apache.activemq.artemis.jms.client.ActiveMQDestination.decomposeQueueNameForDurableSubscription(ActiveMQDestination.java:202)
> 12:43:27,235 ERROR [stderr] (pool-3-thread-4) at 
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listSubscribersInfosAsJSON(JMSTopicControlImpl.java:275)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.apache.activemq.artemis.jms.management.impl.JMSTopicControlImpl.listDurableSubscriptionsAsJSON(JMSTopicControlImpl.java:150)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.wildfly.extension.messaging.activemq.jms.JMSTopicControlHandler.executeRuntimeStep(JMSTopicControlHandler.java:143)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:53)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:877)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:651)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:362)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1336)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:391)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:204)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.execute(ModelControllerMBeanHelper.java:474)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:445)
> 12:43:27,236 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.model.ModelControllerMBeanHelper.invoke(ModelControllerMBeanHelper.java:406)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.model.ModelControllerMBeanServerPlugin.invoke(ModelControllerMBeanServerPlugin.java:175)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:724)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:950)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
> 12:43:27,237 ERROR [stderr] (pool-3-thread-4) at 
> java.security.AccessController.doPrivileged(Native Method)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at 
> javax.security.auth.Subject.doAs(Subject.java:422)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 12:43:27,238 ERROR [stderr] (pool-3-thread-4) at 
> org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
> 12:43:27,238 ERROR [stderr] 

[jira] [Assigned] (ARTEMIS-275) Artemis creating instance request for switch which disables persistance

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram reassigned ARTEMIS-275:
--

Assignee: Justin Bertram

> Artemis creating instance request for switch which disables persistance
> ---
>
> Key: ARTEMIS-275
> URL: https://issues.apache.org/jira/browse/ARTEMIS-275
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Frantisek Reznicek
>Assignee: Justin Bertram
>Priority: Minor
>
> I'd like to request new switch for disabling persistence on create instance 
> interface.
> I understand that create instance is not going to cover all configuration 
> possibilities, but switch like --no-persistance would be good to have there 
> (influencing persistence-enabled xml value).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARTEMIS-271) Expose HttpRequest in WebSocketServerHandler

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-271.

   Resolution: Fixed
Fix Version/s: 1.1.1

> Expose HttpRequest in WebSocketServerHandler
> 
>
> Key: ARTEMIS-271
> URL: https://issues.apache.org/jira/browse/ARTEMIS-271
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Stomp
>Reporter: Julian Scheid
>Priority: Minor
> Fix For: 1.1.1
>
>
> Allows access to the HTTP request used to initiate a WebSocket connection. 
> Enables access to the details of the request, such as cookies and other 
> headers. This is useful e.g. for authorization based on HTTP headers such as 
> {{X-Forwarded-For}} aka {{X-Real-IP}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-269) restart-backup attribute should be true by default

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018978#comment-15018978
 ] 

Justin Bertram commented on ARTEMIS-269:


This looks resolved to me.  Can you confirm, [~andytaylor]?

> restart-backup attribute should be true by default
> --
>
> Key: ARTEMIS-269
> URL: https://issues.apache.org/jira/browse/ARTEMIS-269
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> it makes sense for the default to be true so a backup restarts by default 
> instead of going down



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ARTEMIS-282) Server lock file creation throws exception

[Justin Bertram (JIRA)]

[ 
https://issues.apache.org/jira/browse/ARTEMIS-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018979#comment-15018979
 ] 

Justin Bertram commented on ARTEMIS-282:


This looks resolved to me.  Can you confirm, [~andytaylor]?

> Server lock file creation throws exception
> --
>
> Key: ARTEMIS-282
> URL: https://issues.apache.org/jira/browse/ARTEMIS-282
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.1.0
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>
> This is because there is a check to see if createNewFile which throws an 
> exception on false, this can be removed as another servermay have created it 
> which is fine



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (ARTEMIS-270) Pass RemotingConnection to validateUserAndRole

[Justin Bertram (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ARTEMIS-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Bertram resolved ARTEMIS-270.

   Resolution: Fixed
 Assignee: Justin Bertram
Fix Version/s: 1.1.1

> Pass RemotingConnection to validateUserAndRole
> --
>
> Key: ARTEMIS-270
> URL: https://issues.apache.org/jira/browse/ARTEMIS-270
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Julian Scheid
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 1.1.1
>
>
> By passing the user's RemotingConnection to validateUserAndRole, 
> authorization can take the transport into account. For example, access can be 
> granted only to specific IP addresses or only to in-VM connections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-6044) AMQP: Add support for testing transactions with the test client.

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-6044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15018991#comment-15018991
 ] 

ASF subversion and git services commented on AMQ-6044:
--

Commit 272fb2b97300362f2aaabf78763d62e95d3becaf in activemq's branch 
refs/heads/master from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=272fb2b ]

https://issues.apache.org/jira/browse/AMQ-6044

Add support for transactions to the test client.  

> AMQP: Add support for testing transactions with the test client.
> 
>
> Key: AMQ-6044
> URL: https://issues.apache.org/jira/browse/AMQ-6044
> Project: ActiveMQ
>  Issue Type: Task
>  Components: AMQP
>Affects Versions: 5.12.0, 5.12.1, 5.11.3
>Reporter: Timothy Bish
>Assignee: Timothy Bish
> Fix For: 5.13.0
>
>
> Update the AMQP test client with the ability to do work in transactions and 
> add some transaction based tests to validate broker behaviour. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (AMQ-5489) JMSExpiration not working correctly with LevelDB

[Nevin Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/AMQ-5489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15015392#comment-15015392
 ] 

Nevin Chen commented on AMQ-5489:
-

I also met the same issue in AMQ 5.12.0. Here comes what I did to reproduce 
this issue and the proposal to fix it.

*How to Reproduce*
1. Configure AMQ to send the expired topic message to a queue DLQ and the 
storage is leveldb.
2. A JMS makes a durable subscription to a topic and disconnects after the 
subscription.
3. Another JMS client sends a message with expiration time to the topic in step 
2.
4. After the expiry time, the message will be moved to DLQ. This can be 
monitored by the AMQ web console.
5. Restart AMQ. You will find that the message disappear from the AMQ web 
console. Try to consume the message from the DLQ, nothing is received.

*Cause Analysis*
1. KahaDB works well. It means the cause should be related to the leveldb 
mechanism. 
2. In my understanding, the JMS message is persistent to a log file and leveldb 
will maintain to a reference to the position where the JMS message is stored in 
the log. After a message expires, AMQ will copy the expired JMS message and the 
reference to the posistion is also copied, then send to DLQ. When AMQ restarts, 
DLQ will recover the message from the persistent storage. Since the DLQ message 
shares the same reference to the JMS message data, the message in DLQ also has 
the expiration time that is the same as the original message. The expiry 
scanner will detect the DLQ message expires and remove it. That's why the 
message is lost after restart.
3. Actually, the message to DLQ is not completely the same as the origial 
message. Because the expiration time will be reset to 0 and some more message 
properties will be added. The DLQ message should not reuse the same reference 
to message data. For more details, please refer to 
org.apache.activemq.broker.region.RegionBroker.sendToDeadLetterQueue(ConnectionContext
 context, MessageReference node, Subscription subscription, Throwable 
poisonCause) method.

*Fixed Proposal*
In 
org.apache.activemq.broker.region.RegionBroker.sendToDeadLetterQueue(ConnectionContext
 context, MessageReference node, Subscription subscription, Throwable 
poisonCause) method, after the message is copied, set the dataLocator to null 
(message.getMessageId().setDataLocator(null);) to force leveldb to save the new 
JMS message data and refer to a new position.

> JMSExpiration not working correctly with LevelDB
> 
>
> Key: AMQ-5489
> URL: https://issues.apache.org/jira/browse/AMQ-5489
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: activemq-leveldb-store
>Affects Versions: 5.10.0
> Environment: Solaris and MacOS X, Java 1.6, Camel 2.14 is used for 
> sending messages to the AMQ.
>Reporter: Johannes Pieringer
> Attachments: JConsole_-_ActiveMQ.png, JConsole_-_Retry.png, 
> activemq.xml, jms-expiration-test.zip
>
>
> I'd like to create a setup where messages with an JMSExpiration header expire 
> in a queue named "Retry" and are then moved to the "ActiveMQ.DLQ". The 
> messages should then be consumed from the ActiveMQ.DLQ. As a specialty, the 
> messages are 5MB large.
> The messages do expire in "Retry" and are moved to the "ActiveMQ.DLQ". When 
> the expire however, I instantly see twice the number of expired messages on 
> the "ActiveMQ.DLQ" (see the attached pictures). The following two pictures 
> (JConsole) are taken after the AMQ was started and all previous messages and 
> statistics where deleted during startup. 
> The error happens with LevelDB and ReplicatedLevelDB. It does not occur if 
> KahaDB is used. Furthermore the error does not occure if useCache is true and 
> only a couple of messages are sent. It does occur with useCache is true if 
> many messages are sent. It always happens if useCache is set to false.
> Endpoint URI and Parameters: activemq:queue:Retry?preserveMessageQos=true 
> We also set the JMSExpiration header to 60 seconds in the future. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pablo Lozano updated AMQ-6052:
--
Patch Info: Patch Available

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052-2.patch, AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
> org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
>

[jira] [Updated] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pablo Lozano updated AMQ-6052:
--
Attachment: AMQ_6052-2.patch

Patch with test case included

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052-2.patch, AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
> 

[jira] [Updated] (AMQ-6052) Network of brokers on duplex mode reports InstanceAlreadyExistsException on already existing destinations

[Pablo Lozano (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AMQ-6052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pablo Lozano updated AMQ-6052:
--
Affects Version/s: 5.10.1
   5.12.1

> Network of brokers on duplex mode reports InstanceAlreadyExistsException on 
> already existing destinations
> -
>
> Key: AMQ-6052
> URL: https://issues.apache.org/jira/browse/AMQ-6052
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: networkbridge
>Affects Versions: 5.10.1, 5.12.1, 5.11.3
> Environment: Linux
>Reporter: Pablo Lozano
>  Labels: jmx, networkBridge, networkConnector
> Attachments: AMQ_6052-2.patch, AMQ_6052.patch
>
>
> When using a network of brokers apparently on duplex with destinations which 
> were already created on each MBeanBridgeDestination.onOutboundMessage() and 
> MBeanBridgeDestination.onInboundMessage() the bridge tries to register the 
> MBean of a destination which has already been created.
> Here is a discussion that started but a ticket was not created.
> http://activemq.2283324.n4.nabble.com/Broker-log-full-of-Failed-to-register-queue-messages-td4685241.html
> Although this does not seem to impact the functionality of the application it 
> creates a massive amount of logs as this message repeats for every received 
> message. 
> This are the important bits of my activeMQ configuration:
> {code:xml}
>
>  uri="multicast://default" conduitSubscriptions="true" duplex="true" >
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> connectorPort="1091"
>jmxDomainName="org.apache.activemq"/>
> 
> 
> 
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  discoveryUri="multicast://default" 
> updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
>  updateClusterClients="true"
> rebalanceClusterClients="true" 
> updateClusterClientsOnRemove="true"/>
> 
> {code}
> And this is the output log generated:
> {noformat}
> 2015-11-18 15:43:10,497 [.69:41090@36731] WARN  MBeanBridgeDestination
>  - Failed to register queue://mailsystem.templateprocessor
> javax.management.InstanceAlreadyExistsException: 
> org.apache.activemq:brokerName=mailsystemBroker,connector=duplexNetworkConnectors,networkConnectorName=#0,networkBridge=tcp_//10.211.2.69_41090,type=Broker,direction=inbound,destinationType=Queue,destinationName=mailsystem.templateprocessor
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522)
> at 
> org.apache.activemq.broker.jmx.ManagementContext.registerMBean(ManagementContext.java:380)
> at 
> org.apache.activemq.broker.jmx.AnnotatedMBean.registerMBean(AnnotatedMBean.java:72)
> at 
> org.apache.activemq.network.MBeanBridgeDestination.onInboundMessage(MBeanBridgeDestination.java:97)
> at 
> org.apache.activemq.network.MBeanNetworkListener.onInboundMessage(MBeanNetworkListener.java:115)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceInboundMessage(DemandForwardingBridgeSupport.java:1680)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport.serviceRemoteCommand(DemandForwardingBridgeSupport.java:649)
> at 
> org.apache.activemq.network.DemandForwardingBridgeSupport$3.onCommand(DemandForwardingBridgeSupport.java:224)
> at 
> org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:116)
> at 
> org.apache.activemq.transport.MutexTransport.onCommand(MutexTransport.java:50)
> at 
> org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:113)
> at 
>