[jira] [Commented] (ARTEMIS-1869) Cannot consume using STOMP a message published using MQTT

2018-05-21 Thread Lionel Cons (JIRA) 

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

Lionel Cons commented on ARTEMIS-1869:
--

[~jbertram], the problem comes when changing the message type.

The incoming message is a {{BYTES_TYPE}}. If I change the body without changing 
the message type, everything works as expected. If, in addition, I also change 
the message type by adding:
{code}
  message.setType(Message.TEXT_TYPE);
{code}
then I get the behavior I described: the message is present in the broker but 
cannot be browsed or consumed.

> Cannot consume using STOMP a message published using MQTT
> -
>
> Key: ARTEMIS-1869
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1869
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Priority: Major
>
> I have a test MQTT producer that sends a message to an address. There is a 
> queue bound to this address and I can see the message using the web console. 
> Message count is 1.
> I have a test STOMP consumer subscribing to this queue. It does not get the 
> message.
> If I then start a STOMP publisher to send a message to the same address. The 
> message appears in the same queue. Message count is now 2.
> I then start again the STOMP consumer and it does get the STOMP published 
> message (and message count goes down to 1) but it does not get the MQTT 
> published message. Why?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1872:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2093
  
These following tests are failing:

Test Result (14 failures / +14)

org.apache.activemq.artemis.tests.integration.amqp.JMSConnectionWithSecurityTest.testCreateTemporaryQueueNotAuthorized

org.apache.activemq.artemis.tests.integration.amqp.JMSConnectionWithSecurityTest.testCreateTemporaryTopicNotAuthorized

org.apache.activemq.artemis.tests.integration.jms.consumer.JmsConsumerTest.testValidateExceptionsThroughSharedConsumers

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedNonDurableSubOnDifferentSelector

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedDurableSubOnDifferentSelector

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedDurableSubOnDifferentTopic

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedNonDurableSubOnDifferentSelectorSrcFilterNull

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedDurableSubOnDifferentSelectorSrcFilterNull

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedDurableSubOnDifferentSelectorTargetFilterNull

org.apache.activemq.artemis.tests.integration.jms.jms2client.SharedConsumerTest.sharedNonDurableSubOnDifferentSelectorTargetFilterNull


These tests also failed when I ran but they are probably part of the 
intermittent failures:

org.apache.activemq.artemis.protocol.amqp.util.CreditsSemaphoreTest.testDownAndUp

org.apache.activemq.artemis.tests.integration.cluster.failover.ReplicatedLargeMessageWithDelayFailoverTest.testFailThenReceiveMoreMessagesAfterFailover2

org.apache.activemq.artemis.tests.integration.cluster.reattach.MultiThreadRandomReattachTest.testD

org.apache.activemq.artemis.tests.integration.cluster.reattach.NettyMultiThreadRandomReattachTest.testE


(Although I believe CreditsSemaphoreTest failed because of these changes.. 
I'm not 100% sure)


> Correctly check for queue exists before creating shared queue
> -
>
> Key: ARTEMIS-1872
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1872
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Michael Andre Pearce
>Priority: Major
>
> Prior to 2.5.0, artemis incorrectly always checked the perms for Non Durable 
> on createSharedQueue , even if the queue being created was a Durable queue.
> securityCheck(address, name, CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> In 2.5.0+ this has been corrected, so it checks the permissions appropriately 
> for the durability.
> securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* : 
> CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> This though has exposed that in some area's of the Core client code, and also 
> AMQP, and OpenWire that the code isn't checking that queue exists before 
> calling to create it, meaning a client with consume permission but without 
> create durable queue permissions, would fail but should not as the queue 
> exists.
> Also it was noted on creating the test case to prove this that AMQP JMS 
> Client when security exception occurs, was not correctly throwing 
> JMSSecurityException, this is due to the broker not returning the correct 
> AMQP error code, in these circumstances.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1870) Document Bug: Missing documentation for new parameter "jdbc-journal-sync-period" added for JDBC Persistence

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1870:
-

Github user asfgit closed the pull request at:

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


> Document Bug: Missing documentation for new parameter 
> "jdbc-journal-sync-period" added  for JDBC Persistence
> 
>
> Key: ARTEMIS-1870
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1870
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> As per ARTEMIS-370 new parameter "jdbc-journal-sync-period" added for JDBC 
> Persistence but the documentation was missing for this parameter. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
if I merged this now I would need to use cherry-picks from master into 
2.6.x... if I could wait a week before merging this?


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1870) Document Bug: Missing documentation for new parameter "jdbc-journal-sync-period" added for JDBC Persistence

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1870:
--

Commit 32a92b52e17a10c16e3980885056593fc1b3ca81 in activemq-artemis's branch 
refs/heads/master from [~sarai]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=32a92b5 ]

ARTEMIS-1870:Missing documentation for new parameter jdbc-journal-sync-period 
added for JDBC Persistence


> Document Bug: Missing documentation for new parameter 
> "jdbc-journal-sync-period" added  for JDBC Persistence
> 
>
> Key: ARTEMIS-1870
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1870
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> As per ARTEMIS-370 new parameter "jdbc-journal-sync-period" added for JDBC 
> Persistence but the documentation was missing for this parameter. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1872:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2093
  
I'm running the testsuite first before merging this... 


> Correctly check for queue exists before creating shared queue
> -
>
> Key: ARTEMIS-1872
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1872
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Michael Andre Pearce
>Priority: Major
>
> Prior to 2.5.0, artemis incorrectly always checked the perms for Non Durable 
> on createSharedQueue , even if the queue being created was a Durable queue.
> securityCheck(address, name, CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> In 2.5.0+ this has been corrected, so it checks the permissions appropriately 
> for the durability.
> securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* : 
> CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> This though has exposed that in some area's of the Core client code, and also 
> AMQP, and OpenWire that the code isn't checking that queue exists before 
> calling to create it, meaning a client with consume permission but without 
> create durable queue permissions, would fail but should not as the queue 
> exists.
> Also it was noted on creating the test case to prove this that AMQP JMS 
> Client when security exception occurs, was not correctly throwing 
> JMSSecurityException, this is due to the broker not returning the correct 
> AMQP error code, in these circumstances.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@RaiSaurabh thanks for adding test, i would ask this goes in after a 2.6.1 
release though, as this is new feature, and i think 2.6.1 should just be bug 
fixes to avoid scope of the fix release.


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1874) NPE in ActiveMQMessage.setObjectProperty

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1874:
--

Commit 4d492bea0ee5fb00dcceca9366375cb87d32fe94 in activemq-artemis's branch 
refs/heads/master from [~jbertram]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4d492be ]

ARTEMIS-1874 fix NPE setting object property


> NPE in ActiveMQMessage.setObjectProperty
> 
>
> Key: ARTEMIS-1874
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1874
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Alastair Mailer
>Assignee: Justin Bertram
>Priority: Major
>
> Calling ActiveMQMessage.setObjectProperty("name", null) causes an NPE in 
> handleCoreProperty line 968 (value.toString()) if "name" is either 
> "JMSXGroupID" or "JMSXUserID".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1874) NPE in ActiveMQMessage.setObjectProperty

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1874:
-

Github user asfgit closed the pull request at:

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


> NPE in ActiveMQMessage.setObjectProperty
> 
>
> Key: ARTEMIS-1874
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1874
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Alastair Mailer
>Assignee: Justin Bertram
>Priority: Major
>
> Calling ActiveMQMessage.setObjectProperty("name", null) causes an NPE in 
> handleCoreProperty line 968 (value.toString()) if "name" is either 
> "JMSXGroupID" or "JMSXUserID".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1853) Adding Netty OpenSSL provider test

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1853:
--

Commit 8b458b568268e4364bae94d25535d9373a8a49f8 in activemq-artemis's branch 
refs/heads/master from [~gaohoward]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=8b458b5 ]

ARTEMIS-1853 Adding Netty OpenSSL provider test

Added some netty openssl tests
Fix a NPE issue


> Adding Netty OpenSSL provider test
> --
>
> Key: ARTEMIS-1853
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1853
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> Make sure netty's openssl provider works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1853) Adding Netty OpenSSL provider test

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1853:
-

Github user asfgit closed the pull request at:

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


> Adding Netty OpenSSL provider test
> --
>
> Key: ARTEMIS-1853
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1853
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> Make sure netty's openssl provider works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1868) Openwire doesn't add delivery count in client ack mode

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1868:
-

Github user asfgit closed the pull request at:

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


> Openwire doesn't add delivery count in client ack mode
> --
>
> Key: ARTEMIS-1868
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1868
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> If a client ack mode consumer receives a message and closes without acking 
> it, the redelivery of the message won't set the redelivery flag 
> (JMSRedelivered) because it doesn't increment the delivery count when message 
> is cancelled back to queue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1868) Openwire doesn't add delivery count in client ack mode

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1868:
--

Commit 47b31b53d608f762b9c38e924c5a9f8b92f384b5 in activemq-artemis's branch 
refs/heads/master from [~gaohoward]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=47b31b5 ]

ARTEMIS-1868 Openwire doesn't add delivery count in client ack mode

If a client ack mode consumer receives a message and closes without
acking it, the redelivery of the message won't set the redelivery
flag (JMSRedelivered) because it doesn't increment the delivery count
when message is cancelled back to queue.


> Openwire doesn't add delivery count in client ack mode
> --
>
> Key: ARTEMIS-1868
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1868
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> If a client ack mode consumer receives a message and closes without acking 
> it, the redelivery of the message won't set the redelivery flag 
> (JMSRedelivered) because it doesn't increment the delivery count when message 
> is cancelled back to queue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1868) Openwire doesn't add delivery count in client ack mode

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1868:
--

Commit f24d97bfd11b44c4ac7e672a1ec089ea9db9422a in activemq-artemis's branch 
refs/heads/master from [~nigro@gmail.com]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=f24d97b ]

ARTEMIS-1868 Openwire doesn't add delivery count in client ack mode

If a client ack mode consumer receives a message and closes without
acking it, the redelivery of the message won't set the redelivery
flag (JMSRedelivered) because it doesn't increment the delivery count
when message is cancelled back to queue.
(Perf improvement)


> Openwire doesn't add delivery count in client ack mode
> --
>
> Key: ARTEMIS-1868
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1868
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: OpenWire
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.7.0
>
>
> If a client ack mode consumer receives a message and closes without acking 
> it, the redelivery of the message won't set the redelivery flag 
> (JMSRedelivered) because it doesn't increment the delivery count when message 
> is cancelled back to queue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1875:
-

Github user asfgit closed the pull request at:

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


> Redistribution of messages sometimes does not occur if original message sent 
> using link routing via AMQP
> 
>
> Key: ARTEMIS-1875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
> Fix For: 2.7.0
>
>
> Message redistribution (to another broker in the cluster), relies on the 
> message sender address.  However there are circumstances (such as using link 
> routing via AMQP) when this is not set.  Messages may be lost under these 
> circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

ASF subversion and git services commented on ARTEMIS-1875:
--

Commit 4b04b53bc9b34e622329e890e4b4613cbc385498 in activemq-artemis's branch 
refs/heads/master from [~martyntaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4b04b53 ]

ARTEMIS-1875 Add message address if not set during redistribution


> Redistribution of messages sometimes does not occur if original message sent 
> using link routing via AMQP
> 
>
> Key: ARTEMIS-1875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
> Fix For: 2.7.0
>
>
> Message redistribution (to another broker in the cluster), relies on the 
> message sender address.  However there are circumstances (such as using link 
> routing via AMQP) when this is not set.  Messages may be lost under these 
> circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1875:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2095
  
I ran the whole testsuite and this was fine.. making this failure a non 
issue.

Merging this.


> Redistribution of messages sometimes does not occur if original message sent 
> using link routing via AMQP
> 
>
> Key: ARTEMIS-1875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
> Fix For: 2.7.0
>
>
> Message redistribution (to another broker in the cluster), relies on the 
> message sender address.  However there are circumstances (such as using link 
> routing via AMQP) when this is not set.  Messages may be lost under these 
> circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (AMQ-6968) Incorrect error can be thrown from method that receives a security exception

2018-05-21 Thread Timothy Bish (JIRA) 

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

Timothy Bish resolved AMQ-6968.
---
Resolution: Fixed

> Incorrect error can be thrown from method that receives a security exception
> 
>
> Key: AMQ-6968
> URL: https://issues.apache.org/jira/browse/AMQ-6968
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.15.4
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.16.0, 5.15.5
>
>
> If a client side operation receives an SecurityException as am ErrorResponse 
> and the client closes the connection from the JMS ExceptionListener when the 
> listener is triggered by that exception the Connection ExecutorService could 
> throw a RejectedExecutionException and the client code will pass along that 
> error instead of the originally intended JMSSecurityException



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AMQ-6968) Incorrect error can be thrown from method that receives a security exception

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

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

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

AMQ-6968 Ensure that the correct exception is thrown

Allow the original exception that triggered the failure to be thrown
from the packet send methods

> Incorrect error can be thrown from method that receives a security exception
> 
>
> Key: AMQ-6968
> URL: https://issues.apache.org/jira/browse/AMQ-6968
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.15.4
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.16.0, 5.15.5
>
>
> If a client side operation receives an SecurityException as am ErrorResponse 
> and the client closes the connection from the JMS ExceptionListener when the 
> listener is triggered by that exception the Connection ExecutorService could 
> throw a RejectedExecutionException and the client code will pass along that 
> error instead of the originally intended JMSSecurityException



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AMQ-6968) Incorrect error can be thrown from method that receives a security exception

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

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

Commit 5403ad2e826048d021f8feee888015c45c979514 in activemq's branch 
refs/heads/activemq-5.15.x from [~tabish121]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=5403ad2 ]

AMQ-6968 Ensure that the correct exception is thrown

Allow the original exception that triggered the failure to be thrown
from the packet send methods
(cherry picked from commit db8c771b2a37ad16d789f546507b6329221f4c7a)


> Incorrect error can be thrown from method that receives a security exception
> 
>
> Key: AMQ-6968
> URL: https://issues.apache.org/jira/browse/AMQ-6968
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JMS client
>Affects Versions: 5.15.4
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 5.16.0, 5.15.5
>
>
> If a client side operation receives an SecurityException as am ErrorResponse 
> and the client closes the connection from the JMS ExceptionListener when the 
> listener is triggered by that exception the Connection ExecutorService could 
> throw a RejectedExecutionException and the client code will pass along that 
> error instead of the originally intended JMSSecurityException



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (AMQ-6968) Incorrect error can be thrown from method that receives a security exception

2018-05-21 Thread Timothy Bish (JIRA) 
Timothy Bish created AMQ-6968:
-

 Summary: Incorrect error can be thrown from method that receives a 
security exception
 Key: AMQ-6968
 URL: https://issues.apache.org/jira/browse/AMQ-6968
 Project: ActiveMQ
  Issue Type: Bug
  Components: JMS client
Affects Versions: 5.15.4
Reporter: Timothy Bish
Assignee: Timothy Bish
 Fix For: 5.16.0, 5.15.5


If a client side operation receives an SecurityException as am ErrorResponse 
and the client closes the connection from the JMS ExceptionListener when the 
listener is triggered by that exception the Connection ExecutorService could 
throw a RejectedExecutionException and the client code will pass along that 
error instead of the originally intended JMSSecurityException



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread clebert suconic (JIRA) 

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

clebert suconic updated ARTEMIS-1875:
-
Fix Version/s: 2.7.0

> Redistribution of messages sometimes does not occur if original message sent 
> using link routing via AMQP
> 
>
> Key: ARTEMIS-1875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
> Fix For: 2.7.0
>
>
> Message redistribution (to another broker in the cluster), relies on the 
> message sender address.  However there are circumstances (such as using link 
> routing via AMQP) when this is not set.  Messages may be lost under these 
> circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1875:
-

GitHub user mtaylor opened a pull request:

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

ARTEMIS-1875 Add message address if not set during redistribution



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

$ git pull https://github.com/mtaylor/activemq-artemis ARTEMIS-1875

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

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


commit 4b04b53bc9b34e622329e890e4b4613cbc385498
Author: Martyn Taylor 
Date:   2018-05-21T17:21:26Z

ARTEMIS-1875 Add message address if not set during redistribution




> Redistribution of messages sometimes does not occur if original message sent 
> using link routing via AMQP
> 
>
> Key: ARTEMIS-1875
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
>
> Message redistribution (to another broker in the cluster), relies on the 
> message sender address.  However there are circumstances (such as using link 
> routing via AMQP) when this is not set.  Messages may be lost under these 
> circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1875) Redistribution of messages sometimes does not occur if original message sent using link routing via AMQP

2018-05-21 Thread Martyn Taylor (JIRA) 
Martyn Taylor created ARTEMIS-1875:
--

 Summary: Redistribution of messages sometimes does not occur if 
original message sent using link routing via AMQP
 Key: ARTEMIS-1875
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1875
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.6.0
Reporter: Martyn Taylor
Assignee: Martyn Taylor


Message redistribution (to another broker in the cluster), relies on the 
message sender address.  However there are circumstances (such as using link 
routing via AMQP) when this is not set.  Messages may be lost under these 
circumstances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1874) NPE in ActiveMQMessage.setObjectProperty

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1874:
-

GitHub user jbertram opened a pull request:

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

ARTEMIS-1874 fix NPE setting object property



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

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

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

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


commit 29aa0d340b12e84aae6047f18a5759b94495652e
Author: Justin Bertram 
Date:   2018-05-21T14:55:15Z

ARTEMIS-1874 fix NPE setting object property




> NPE in ActiveMQMessage.setObjectProperty
> 
>
> Key: ARTEMIS-1874
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1874
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Alastair Mailer
>Priority: Major
>
> Calling ActiveMQMessage.setObjectProperty("name", null) causes an NPE in 
> handleCoreProperty line 968 (value.toString()) if "name" is either 
> "JMSXGroupID" or "JMSXUserID".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ARTEMIS-1874) NPE in ActiveMQMessage.setObjectProperty

2018-05-21 Thread Justin Bertram (JIRA) 

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

Justin Bertram reassigned ARTEMIS-1874:
---

Assignee: Justin Bertram

> NPE in ActiveMQMessage.setObjectProperty
> 
>
> Key: ARTEMIS-1874
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1874
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Alastair Mailer
>Assignee: Justin Bertram
>Priority: Major
>
> Calling ActiveMQMessage.setObjectProperty("name", null) causes an NPE in 
> handleCoreProperty line 968 (value.toString()) if "name" is either 
> "JMSXGroupID" or "JMSXUserID".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AMQ-6967) Periodic expiry with no consumers fails to page in messages if cache has flipped

2018-05-21 Thread ASF subversion and git services (JIRA) 

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

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

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

AMQ-6967 - ensure there are some messages paged in for periodic expiry check if 
non are in memory


> Periodic expiry with no consumers fails to page in messages if cache has 
> flipped
> 
>
> Key: AMQ-6967
> URL: https://issues.apache.org/jira/browse/AMQ-6967
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Message Store
>Affects Versions: 5.15.0
>Reporter: Gary Tully
>Assignee: Gary Tully
>Priority: Major
> Fix For: 5.16.0
>
>
> when there are no consumers on a queue and message sends push the cursor to 
> the default 70% memory limit, message expiry can fail to page in messages.
> The logic respects the cursor memory limit but fails to account for never 
> having done a page in for browse/expiry or dispatch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (AMQ-6967) Periodic expiry with no consumers fails to page in messages if cache has flipped

2018-05-21 Thread Gary Tully (JIRA) 
Gary Tully created AMQ-6967:
---

 Summary: Periodic expiry with no consumers fails to page in 
messages if cache has flipped
 Key: AMQ-6967
 URL: https://issues.apache.org/jira/browse/AMQ-6967
 Project: ActiveMQ
  Issue Type: Bug
  Components: Message Store
Affects Versions: 5.15.0
Reporter: Gary Tully
Assignee: Gary Tully
 Fix For: 5.16.0


when there are no consumers on a queue and message sends push the cursor to the 
default 70% memory limit, message expiry can fail to page in messages.

The logic respects the cursor memory limit but fails to account for never 
having done a page in for browse/expiry or dispatch



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1874) NPE in ActiveMQMessage.setObjectProperty

2018-05-21 Thread Alastair Mailer (JIRA) 
Alastair Mailer created ARTEMIS-1874:


 Summary: NPE in ActiveMQMessage.setObjectProperty
 Key: ARTEMIS-1874
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1874
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Alastair Mailer


Calling ActiveMQMessage.setObjectProperty("name", null) causes an NPE in 
handleCoreProperty line 968 (value.toString()) if "name" is either 
"JMSXGroupID" or "JMSXUserID".



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (AMQ-6966) mqtt over wss impossible get certificate details

2018-05-21 Thread Christopher L. Shannon (JIRA) 

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

Christopher L. Shannon commented on AMQ-6966:
-

Most likely you need to configure your transport to want or need a client 
certificate otherwise it won't be available. For example:

{{wss://localhost:61623?transport.needClientAuth=true}}

or 

{{wss://localhost:61623?transport.wantClientAuth=true}}

> mqtt over wss impossible get certificate details
> 
>
> Key: AMQ-6966
> URL: https://issues.apache.org/jira/browse/AMQ-6966
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: MQTT
>Affects Versions: 5.15.3
>Reporter: Jose
>Priority: Major
>
> steps:
>  * connect from paho mqtt client to mqtt+ssl transport in activemq
>  * from plugin addConnection function call info.getTransportContext
> Expected, transportContext is an instance of X509Certificate[] so i can 
> extract certificate details
>  
> Issue:
> Execute the same but connect to wss transport in activemq
> info.getTransportContext return null



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (ARTEMIS-1873) AMQ222068: STOMP heartbeat handler is not stopped after StompConnection.destroy()

2018-05-21 Thread JIRA 
Paweł Puterla created ARTEMIS-1873:
--

 Summary: AMQ222068: STOMP heartbeat handler is not stopped after 
StompConnection.destroy()
 Key: ARTEMIS-1873
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1873
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: STOMP
Affects Versions: 2.7.0
Reporter: Paweł Puterla
Assignee: Justin Bertram


StompConnection.java (it's in artemis-stomp-protocol) utilizes a "

VersionedStompFrameHandler" frame handler which (in case of STOMP 1.1 and 1.2) 
contains a heartbeat scheduler.

This scheduler is stopped when StompConnection.fail() is called but not for 
.destroy().

So in some cases you may get dangling heartbeat threads from destroyed 
connections. These threads simply try to send heartbeats to dead clients 
resulting in following warnings:

 
{noformat}
2018-05-17 17:01:06,591 WARN  [org.apache.activemq.artemis.core.protocol.stomp] 
(Thread-22 
(ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$3@6b9ec8e5))
 AMQ222068: connection closed 
org.apache.activemq.artemis.core.protocol.stomp.StompConnection@5d5327f9{noformat}
 

In my opinion it's just a simple oversight. From what I see ARTEMIS-934 did 
only fix the issue for .fail() method. But RemoteConnections (which is 
StompConnection) can also be destroy()'ed.

 

Here's example diff that may fix it:
{code:java}
diff --git 
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
 
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
index fbd010775..4c11108c3 100644
--- 
a/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
+++ 
b/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/StompConnection.java
@@ -335,9 +335,10 @@ public final class StompConnection implements 
RemotingConnection {
  if (destroyed) {
 return;
  }
+
+ destroyed = true;
   }

-  destroyed = true;

   internalClose();

@@ -351,6 +352,10 @@ public final class StompConnection implements 
RemotingConnection {
    }

    private void internalClose() {
+  if (frameHandler != null) {
+ frameHandler.disconnect();
+  }
+
   transportConnection.close();

   manager.cleanup(this);
@@ -372,9 +377,6 @@ public final class StompConnection implements 
RemotingConnection {

   ActiveMQServerLogger.LOGGER.connectionFailureDetected(me.getMessage(), 
me.getType());

-  if (frameHandler != null) {
- frameHandler.disconnect();
-  }

   // Then call the listeners
   callFailureListeners(me);

{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1872) Correctly check for queue exists before creating shared queue

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1872:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2093
  
@michaelandrepearce Yep, makes sense indeed. I will probably implemented it 
in the same you've done (on Core). I haven't finished to read the AMQP part yet 
:+1: 


> Correctly check for queue exists before creating shared queue
> -
>
> Key: ARTEMIS-1872
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1872
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Michael Andre Pearce
>Priority: Major
>
> Prior to 2.5.0, artemis incorrectly always checked the perms for Non Durable 
> on createSharedQueue , even if the queue being created was a Durable queue.
> securityCheck(address, name, CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> In 2.5.0+ this has been corrected, so it checks the permissions appropriately 
> for the durability.
> securityCheck(address, name, durable ? CheckType.*_CREATE_DURABLE_QUEUE_* : 
> CheckType.*_CREATE_NON_DURABLE_QUEUE_*, *this*);
>  
> This though has exposed that in some area's of the Core client code, and also 
> AMQP, and OpenWire that the code isn't checking that queue exists before 
> calling to create it, meaning a client with consume permission but without 
> create durable queue permissions, would fail but should not as the queue 
> exists.
> Also it was noted on creating the test case to prove this that AMQP JMS 
> Client when security exception occurs, was not correctly throwing 
> JMSSecurityException, this is due to the broker not returning the correct 
> AMQP error code, in these circumstances.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ARTEMIS-1866) Make wait time for reply configurable once vote goes out to acquire a quorum.

2018-05-21 Thread ASF GitHub Bot (JIRA) 

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

ASF GitHub Bot commented on ARTEMIS-1866:
-

Github user RaiSaurabh commented on the issue:

https://github.com/apache/activemq-artemis/pull/2089
  
@franz1981 @michaelandrepearce I have added the test case to check for 
default 30 is used if not set or configured.  I hope now it is okay.


> Make wait time for reply configurable once vote goes out to acquire a quorum.
> -
>
> Key: ARTEMIS-1866
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1866
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Saurabh Rai
>Priority: Major
>
> Quorum voting is used by both the live and the backup to decide what to do if 
> a replication connection is disconnected. Basically, the server will request 
> each live server in the cluster to vote as to whether it thinks the server it 
> is replicating to or from is still alive. You can also configure the time for 
> which the quorum manager will wait for the quorum vote response. Currently, 
> the value is hardcoded as 30 sec. We should change this 30-second wait to be 
> configurable.
> Please find the logs for reference:
> 2018-05-06 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] 
> AMQ221066: Initiating quorum vote: LiveFailoverQuorumVote 2018-05-06 
> 11:20:42,906 INFO [org.apache.activemq.artemis.core.server] AMQ221067: 
> Waiting 30 seconds for quorum vote results. 2018-05-06 11:20:42,914 INFO 
> [org.apache.activemq.artemis.core.server] AMQ221060: Sending quorum vote 
> request to amq2a/10.92.151.33:61716: ServerConnectVote 
> [nodeId=d41a0e0f-50da-11e8-9b2d-005056b01f85, vote=false]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)