[jira] [Commented] (AMQ-6912) Update website

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce commented on AMQ-6912:
---

A rough proposed sitemap can be found here: [^ActiveMQSiteMap.docx]

> Update website 
> ---
>
> Key: AMQ-6912
> URL: https://issues.apache.org/jira/browse/AMQ-6912
> Project: ActiveMQ
>  Issue Type: Task
>Reporter: Martyn Taylor
>Priority: Major
> Attachments: ActiveMQSiteMap.docx
>
>
> Tracker Jira for website update.  [~amp001] has created a proposal using 
> Jekyll.  It requires some work before it could be proposed to go live.  This 
> is tracking that work.



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

[jira] [Updated] (AMQ-6912) Update website

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce updated AMQ-6912:
--
Attachment: ActiveMQSiteMap.docx

> Update website 
> ---
>
> Key: AMQ-6912
> URL: https://issues.apache.org/jira/browse/AMQ-6912
> Project: ActiveMQ
>  Issue Type: Task
>Reporter: Martyn Taylor
>Priority: Major
> Attachments: ActiveMQSiteMap.docx
>
>
> Tracker Jira for website update.  [~amp001] has created a proposal using 
> Jekyll.  It requires some work before it could be proposed to go live.  This 
> is tracking that work.



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

[jira] [Commented] (AMQ-6912) Update website

[Michael Andre Pearce (JIRA)]

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

Michael Andre Pearce commented on AMQ-6912:
---

Initial work can be found here: 
[https://github.com/michaelandrepearce/activemq-site/tree/master/site]

 

 

> Update website 
> ---
>
> Key: AMQ-6912
> URL: https://issues.apache.org/jira/browse/AMQ-6912
> Project: ActiveMQ
>  Issue Type: Task
>Reporter: Martyn Taylor
>Priority: Major
>
> Tracker Jira for website update.  [~amp001] has created a proposal using 
> Jekyll.  It requires some work before it could be proposed to go live.  This 
> is tracking that work.



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

[jira] [Commented] (ARTEMIS-1562) Refactor example documentation

[ASF subversion and git services (JIRA)]

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

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

Commit 5ab187b7fef5ed6ad8a857287417f55878678714 in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5ab187b ]

ARTEMIS-1562 Fixing typos on examples


> Refactor example documentation
> --
>
> Key: ARTEMIS-1562
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1562
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 2.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Commented] (ARTEMIS-1562) Refactor example documentation

[ASF subversion and git services (JIRA)]

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

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

Commit ee54954f2a45c7db02c6637d62cd93255fa3cb57 in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=ee54954 ]

ARTEMIS-1562 Fixing typo on example


> Refactor example documentation
> --
>
> Key: ARTEMIS-1562
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1562
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 2.4.0
>Reporter: Justin Bertram
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Commented] (AMQ-6781) The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on AMQ-6781:
-

GitHub user snurmine opened a pull request:

https://github.com/apache/activemq/pull/279

AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign i…

…n the ClientID

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

$ git pull https://github.com/snurmine/activemq AMQ-6781

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

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


commit 680b80aa22063e009b14ec59df54c60fdb17d975
Author: Sami Nurminen 
Date:   2017-12-21T19:50:11Z

AMQ-6781 - The ActiveMQ Web Console doesn’t support a plus (+) sign in the 
ClientID




> The ActiveMQ Web Console doesn’t support a plus (+) sign in the ClientID
> 
>
> Key: AMQ-6781
> URL: https://issues.apache.org/jira/browse/AMQ-6781
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.14.1, 5.15.0
>Reporter: Patrick Vansevenant
>Priority: Minor
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> I’m trying to use an ISO 8601 date/time as part of the ClientID. 
> For example : connection.setClientID(" id>|2017-08-01T09:20:18.936+03:00"); 
> !screenshot-1.png!
> The following error is generated when clicked on the url in the Web Console | 
> Connections page : 
> !screenshot-2.png!
> I see that the ‘+’ sign isn’t correct encoded in the URL. 
> It is : *{color:red}+{color}* 
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*+*{color}03:00
>  
> And it should perhaps be : *{color:red}%2B {color}*
> http://testactivemq:8161/admin/connection.jsp?connectionID=%3Cmy%20unique%20id%3E|2017-08-01T09:20:18.936{color:red}*%2B*{color}03:00
>  



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

[jira] [Commented] (ARTEMIS-1682) duplicate classes in Artemis jars

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1682 Added back test-jar artemis-server test-jar


> duplicate classes in Artemis jars
> -
>
> Key: ARTEMIS-1682
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1682
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jeff Mesnil
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: 2.5.0
>
>
> This is a recent change in Artemis master branch.
> The org.apache.activemq.artemis.utils package whose source files are in 
> artemis-commons are also present in the artemis-server jar.
>  
> {code:java}
> $ find . -name ExecutorFactory.java
> ./artemis-commons/src/main/java/org/apache/activemq/artemis/utils/ExecutorFactory.java
> $ jar tvf artemis-commons/target/artemis-commons-2.5.0-SNAPSHOT.jar | grep 
> ExecutorFactory
> 2335 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/actors/OrderedExecutorFactory.class
> 230 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/ExecutorFactory.class
> $ jar tvf artemis-server/target/artemis-server-2.5.0-SNAPSHOT.jar | grep 
> ExecutorFactory
> 230 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/ExecutorFactory.class
> {code}
>  
> This causes issue when we integrate Artemis on our application server that is 
> using a modular class loader as there are 2 definitions of the 
> ExecutorFactory class and we end up with weird errors such as:
> {code}
> 12:02:16,754 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 
> 68) MSC01: Failed to start service 
> jboss.messaging-activemq.default.jms.manager: 
> org.jboss.msc.service.StartException in service 
> jboss.messaging-activemq.default.jms.manager: 
> java.lang.IncompatibleClassChangeError: Class 
> org.apache.activemq.artemis.utils.actors.OrderedExecutorFactory does not 
> implement the requested interface 
> org.apache.activemq.artemis.utils.ExecutorFactory
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:209)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at 
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at 
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IncompatibleClassChangeError: Class 
> org.apache.activemq.artemis.utils.actors.OrderedExecutorFactory does not 
> implement the requested interface 
> org.apache.activemq.artemis.utils.ExecutorFactory
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:222)
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:106)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2151)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2287)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:392)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205)
> ... 9 more
> {code}
> This happens because the ActiveMQServerImpl is referencing the 
> ExecutorFactory class from artemis-server jar while the 
> OrderedExecutorFactory class is referencing the ExecutorFactory class from 
> artemis-commons.



--
This message was sent by 

[jira] [Created] (ARTEMIS-1742) possible problem with embedded broker and vm acceptor/connector

[Andrea Tarocchi (JIRA)]

Andrea Tarocchi created ARTEMIS-1742:


 Summary: possible problem with embedded broker and vm 
acceptor/connector
 Key: ARTEMIS-1742
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1742
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.3.0
Reporter: Andrea Tarocchi
 Attachments: camel-jms.zip

In camel-jms component we keep having some random failing tests using embedded 
artemis broker.

Basically the same tests are run using embedded artemis broker and embedded amq 
broker and the same test is re ran up to 3 times if it has a failure (in that 
case is marked as flaky), we keep experiencing flaky tests for artemis and not 
for amq.

I've attached a simplified as possible reproducer which run the same test 50 
times only using artemis embedded broker (is a pretty simple write and read 
from a temp queue).

Running it a couple of times with: \{{mvn clean test}} should manifest the 
flaky behaviour.

Might be we init/destroy the embedded broker in the wrong way?
{code:java}
public ConnectionFactory createConnectionFactory(final int 
maximumRedeliveries, final boolean persistent) {
int id = BROKER_COUNT.incrementAndGet();
String baseDir = DATA_DIR + File.separator + id;
final Configuration configuration;
try {
configuration = new ConfigurationImpl()
.setPersistenceEnabled(persistent)
.setSecurityEnabled(false)
.setBindingsDirectory(baseDir + File.separator + "bindings")
.setJournalDirectory(baseDir + File.separator + "journal")
.setPagingDirectory(baseDir + File.separator + "paging")
.setLargeMessagesDirectory(baseDir + File.separator + 
"largemessages")


.setCheckForLiveServer(false)
.setEnabledAsyncConnectionExecution(false)
.setManagementNotificationAddress( new 
SimpleString("activemq.notifications") )


.setCheckForLiveServer(false)
.setClusterConfigurations( new ArrayList<>() )


.addAcceptorConfiguration("invm", "vm://" + id)
.addConnectorConfiguration("invm", "vm://" + id);
} catch (final Exception e) {
throw new ExceptionInInitializerError(e);
}


final ConnectionFactoryConfiguration cfConfig = new 
ConnectionFactoryConfigurationImpl().setName("cf")
.setConnectorNames("invm").setBindings("cf");


final JMSConfiguration jmsConfig = new JMSConfigurationImpl()
.setConnectionFactoryConfigurations(singletonList(cfConfig));


EmbeddedJMS broker = new 
EmbeddedJMS().setConfiguration(configuration).setJmsConfiguration(jmsConfig);


try {
broker.start();
} catch (final Exception e) {
throw new ExceptionInInitializerError(e);
}

final AddressSettings addressSettings = new AddressSettings()

.setMaxDeliveryAttempts(maximumRedeliveries)

.setDeadLetterAddress(new SimpleString("jms.queue.deadletter"))
.setExpiryAddress(new 
SimpleString("jms.queue.expired"))
.setAutoCreateAddresses(true)

.setAutoCreateQueues(true);
broker.getActiveMQServer().getAddressSettingsRepository().addMatch("#", 
addressSettings);

TransportConfiguration transportConfigs = new 
TransportConfiguration(InVMConnectorFactory.class.getName());

transportConfigs.getParams().put(TransportConstants.SERVER_ID_PROP_NAME, id);
ServerLocator serviceLocator = 
ActiveMQClient.createServerLocator(false, transportConfigs);

ActiveMQConnectionFactory acf = new 
ActiveMQConnectionFactory(serviceLocator);

return acf;
}
{code}
 



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

[jira] [Commented] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[ASF subversion and git services (JIRA)]

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

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

Commit 3c6876ece61880dbe1a5ea0f50f43e13b803dded in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=3c6876e ]

ARTEMIS-1741 - log warning if a node isnt configured for quorum voting

https://issues.apache.org/jira/browse/ARTEMIS-1741


> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Commented] (ARTEMIS-1514) Implementing AMQP LargeMessage

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-1514:
--

It's partially done...

we convert large messages as regular messages, but we don't stream yet.

> Implementing AMQP LargeMessage
> --
>
> Key: ARTEMIS-1514
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1514
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Commented] (ARTEMIS-1732) AMQP anonymous producer not blocked on max-disk-usage

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-1732:
--

doesn't seem like done... defer it

> AMQP anonymous producer not blocked on max-disk-usage
> -
>
> Key: ARTEMIS-1732
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1732
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.4.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.5.0
>
>
> Anonymous senders (those created without a target address) are not blocked 
> when max-disk-usage is reached. The cause is that when such a sender is 
> created on the broker, the broker doesn't check the disk/memory usage and 
> gives out the credit immediately.



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

[jira] [Resolved] (ARTEMIS-1737) When live-slave fails-back to master, it turns off everything down, even its console

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-1737.
-
   Resolution: Fixed
Fix Version/s: 2.5.0

> When live-slave fails-back to master, it turns off everything down, even its 
> console
> 
>
> Key: ARTEMIS-1737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> 1) Set up HA pair with slave {{true}}
> 2) Kill master
> 3) Make sure slave becomes live
> 4) Start master again, slave gives control to master and becomes a slave
> 5) Console of slave (backup now) becomes inaccessible



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

[jira] [Resolved] (ARTEMIS-1739) default module name for artemis-native uses reserved keyword

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-1739.
-
   Resolution: Fixed
Fix Version/s: 2.5.0

> default module name for artemis-native uses reserved keyword
> 
>
> Key: ARTEMIS-1739
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1739
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> We can override this in the manifest.  I will rename as artemis.jni



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

[jira] [Commented] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[ASF subversion and git services (JIRA)]

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

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

Commit 3c6876ece61880dbe1a5ea0f50f43e13b803dded in activemq-artemis's branch 
refs/heads/master from [~andytaylor]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=3c6876e ]

ARTEMIS-1741 - log warning if a node isnt configured for quorum voting

https://issues.apache.org/jira/browse/ARTEMIS-1741


> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Resolved] (ARTEMIS-1682) duplicate classes in Artemis jars

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-1682.
-
   Resolution: Fixed
Fix Version/s: 2.5.0

> duplicate classes in Artemis jars
> -
>
> Key: ARTEMIS-1682
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1682
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Jeff Mesnil
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: 2.5.0
>
>
> This is a recent change in Artemis master branch.
> The org.apache.activemq.artemis.utils package whose source files are in 
> artemis-commons are also present in the artemis-server jar.
>  
> {code:java}
> $ find . -name ExecutorFactory.java
> ./artemis-commons/src/main/java/org/apache/activemq/artemis/utils/ExecutorFactory.java
> $ jar tvf artemis-commons/target/artemis-commons-2.5.0-SNAPSHOT.jar | grep 
> ExecutorFactory
> 2335 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/actors/OrderedExecutorFactory.class
> 230 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/ExecutorFactory.class
> $ jar tvf artemis-server/target/artemis-server-2.5.0-SNAPSHOT.jar | grep 
> ExecutorFactory
> 230 Wed Feb 14 09:30:54 CET 2018 
> org/apache/activemq/artemis/utils/ExecutorFactory.class
> {code}
>  
> This causes issue when we integrate Artemis on our application server that is 
> using a modular class loader as there are 2 definitions of the 
> ExecutorFactory class and we end up with weird errors such as:
> {code}
> 12:02:16,754 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 
> 68) MSC01: Failed to start service 
> jboss.messaging-activemq.default.jms.manager: 
> org.jboss.msc.service.StartException in service 
> jboss.messaging-activemq.default.jms.manager: 
> java.lang.IncompatibleClassChangeError: Class 
> org.apache.activemq.artemis.utils.actors.OrderedExecutorFactory does not 
> implement the requested interface 
> org.apache.activemq.artemis.utils.ExecutorFactory
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:209)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.access$000(JMSService.java:64)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService$1.run(JMSService.java:99)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at 
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at 
> org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1348)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:485)
> Caused by: java.lang.IncompatibleClassChangeError: Class 
> org.apache.activemq.artemis.utils.actors.OrderedExecutorFactory does not 
> implement the requested interface 
> org.apache.activemq.artemis.utils.ExecutorFactory
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.AbstractJournalStorageManager.(AbstractJournalStorageManager.java:222)
> at 
> org.apache.activemq.artemis.core.persistence.impl.journal.JournalStorageManager.(JournalStorageManager.java:106)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createStorageManager(ActiveMQServerImpl.java:2151)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart1(ActiveMQServerImpl.java:2287)
> at 
> org.apache.activemq.artemis.core.server.impl.LiveOnlyActivation.run(LiveOnlyActivation.java:63)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.internalStart(ActiveMQServerImpl.java:522)
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.start(ActiveMQServerImpl.java:461)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.start(JMSServerManagerImpl.java:392)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSService.doStart(JMSService.java:205)
> ... 9 more
> {code}
> This happens because the ActiveMQServerImpl is referencing the 
> ExecutorFactory class from artemis-server jar while the 
> OrderedExecutorFactory class is referencing the ExecutorFactory class from 
> artemis-commons.



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

[jira] [Commented] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1741:
-

Github user asfgit closed the pull request at:

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


> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Resolved] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[Justin Bertram (JIRA)]

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

Justin Bertram resolved ARTEMIS-1741.
-
Resolution: Fixed

> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Commented] (ARTEMIS-1737) When live-slave fails-back to master, it turns off everything down, even its console

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1737 fix for inaccessible slave console after failover


> When live-slave fails-back to master, it turns off everything down, even its 
> console
> 
>
> Key: ARTEMIS-1737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> 1) Set up HA pair with slave {{true}}
> 2) Kill master
> 3) Make sure slave becomes live
> 4) Start master again, slave gives control to master and becomes a slave
> 5) Console of slave (backup now) becomes inaccessible



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

[jira] [Commented] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1676:
-

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1862
  
closing will reopen with suggestions


> Allow users to override JAVA_ARGS via environment variables
> ---
>
> Key: ARTEMIS-1676
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1676
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Priority: Major
>
> We currently require users to update the artemis.profile file to change 
> JAVA_ARGS options.   However, it's often useful to be able to override 
> certain properties via environment variables.  Typical example is when 
> running in a cloud environment, where customisation is often injected via 
> environment variables.



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

[jira] [Commented] (ARTEMIS-1737) When live-slave fails-back to master, it turns off everything down, even its console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1737:
-

Github user asfgit closed the pull request at:

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


> When live-slave fails-back to master, it turns off everything down, even its 
> console
> 
>
> Key: ARTEMIS-1737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> 1) Set up HA pair with slave {{true}}
> 2) Kill master
> 3) Make sure slave becomes live
> 4) Start master again, slave gives control to master and becomes a slave
> 5) Console of slave (backup now) becomes inaccessible



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

[jira] [Commented] (ARTEMIS-1676) Allow users to override JAVA_ARGS via environment variables

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1676:
-

Github user mtaylor closed the pull request at:

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


> Allow users to override JAVA_ARGS via environment variables
> ---
>
> Key: ARTEMIS-1676
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1676
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Priority: Major
>
> We currently require users to update the artemis.profile file to change 
> JAVA_ARGS options.   However, it's often useful to be able to override 
> certain properties via environment variables.  Typical example is when 
> running in a cloud environment, where customisation is often injected via 
> environment variables.



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

[jira] [Commented] (ARTEMIS-1737) When live-slave fails-back to master, it turns off everything down, even its console

[ASF subversion and git services (JIRA)]

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

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

Commit 91c0452d601729585cd75e4d74c473b92f3bd1af in activemq-artemis's branch 
refs/heads/master from Clebert Suconic
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=91c0452 ]

ARTEMIS-1737 Fixing semantic of ServerControl.forceFailover

This closes #1940


> When live-slave fails-back to master, it turns off everything down, even its 
> console
> 
>
> Key: ARTEMIS-1737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> 1) Set up HA pair with slave {{true}}
> 2) Kill master
> 3) Make sure slave becomes live
> 4) Start master again, slave gives control to master and becomes a slave
> 5) Console of slave (backup now) becomes inaccessible



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

[jira] [Commented] (ARTEMIS-1737) When live-slave fails-back to master, it turns off everything down, even its console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1737:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/1945
  
@michaelandrepearce when isExit=true, it means the VM is going away. The 
previous task was to shutdown the server upon a forceCall, on that case isExit 
must be true.

I changed it to the previous method and I am using @stanlyDoge's test to 
validate it.


> When live-slave fails-back to master, it turns off everything down, even its 
> console
> 
>
> Key: ARTEMIS-1737
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1737
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> 1) Set up HA pair with slave {{true}}
> 2) Kill master
> 3) Make sure slave becomes live
> 4) Start master again, slave gives control to master and becomes a slave
> 5) Console of slave (backup now) becomes inaccessible



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

[jira] [Commented] (AMQ-6924) StoreDurableSubscriberCursor does not timeout properly on non-persistent message send

[ASF subversion and git services (JIRA)]

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

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

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

AMQ-6924 - Fix StoreDurableSubscriberCursor non-persistent message add

StoreDurableSubscriberCursor now properly uses a timeout value when
attempting to add to the temporary store for non-persistent messages to
prevent an indefinite wait on free space


> StoreDurableSubscriberCursor does not timeout properly on non-persistent 
> message send
> -
>
> Key: AMQ-6924
> URL: https://issues.apache.org/jira/browse/AMQ-6924
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.3
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.16.0, 5.15.4
>
>
> I found an issue today on a broker when the temporary store was full and a 
> non-persistent message was trying to be added to a durable subscription.  
> Analysis showed that the broker was stuck in a loop trying to add the 
> non-persistent message to the temporary store because the maxWaitTime value 
> is not properly used inside of StoreDurableSubscriberCursor. Instead of 
> honoring a timeout value and failing, the waitForSpace() method call on the 
> temporary store was stuck in a loop waiting indefinitely for free space.



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

[jira] [Commented] (AMQ-6924) StoreDurableSubscriberCursor does not timeout properly on non-persistent message send

[ASF subversion and git services (JIRA)]

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

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

Commit 2ca46c561b3954c7065e09be92bf05e128357a73 in activemq's branch 
refs/heads/activemq-5.15.x from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=2ca46c5 ]

AMQ-6924 - Fix StoreDurableSubscriberCursor non-persistent message add

StoreDurableSubscriberCursor now properly uses a timeout value when
attempting to add to the temporary store for non-persistent messages to
prevent an indefinite wait on free space

(cherry picked from commit 5e2adc0ed7dfe2e827bdef878f1c8cde12ff5773)


> StoreDurableSubscriberCursor does not timeout properly on non-persistent 
> message send
> -
>
> Key: AMQ-6924
> URL: https://issues.apache.org/jira/browse/AMQ-6924
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.3
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.16.0, 5.15.4
>
>
> I found an issue today on a broker when the temporary store was full and a 
> non-persistent message was trying to be added to a durable subscription.  
> Analysis showed that the broker was stuck in a loop trying to add the 
> non-persistent message to the temporary store because the maxWaitTime value 
> is not properly used inside of StoreDurableSubscriberCursor. Instead of 
> honoring a timeout value and failing, the waitForSpace() method call on the 
> temporary store was stuck in a loop waiting indefinitely for free space.



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

[jira] [Resolved] (AMQ-6924) StoreDurableSubscriberCursor does not timeout properly on non-persistent message send

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon resolved AMQ-6924.
-
Resolution: Fixed

> StoreDurableSubscriberCursor does not timeout properly on non-persistent 
> message send
> -
>
> Key: AMQ-6924
> URL: https://issues.apache.org/jira/browse/AMQ-6924
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.3
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.16.0, 5.15.4
>
>
> I found an issue today on a broker when the temporary store was full and a 
> non-persistent message was trying to be added to a durable subscription.  
> Analysis showed that the broker was stuck in a loop trying to add the 
> non-persistent message to the temporary store because the maxWaitTime value 
> is not properly used inside of StoreDurableSubscriberCursor. Instead of 
> honoring a timeout value and failing, the waitForSpace() method call on the 
> temporary store was stuck in a loop waiting indefinitely for free space.



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

[jira] [Updated] (AMQ-6924) StoreDurableSubscriberCursor does not timeout properly on non-persistent message send

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon updated AMQ-6924:

Description: I found an issue today on a broker when the temporary store 
was full and a non-persistent message was trying to be added to a durable 
subscription.  Analysis showed that the broker was stuck in a loop trying to 
add the non-persistent message to the temporary store because the maxWaitTime 
value is not properly used inside of StoreDurableSubscriberCursor. Instead of 
honoring a timeout value and failing, the waitForSpace() method call on the 
temporary store was stuck in a loop waiting indefinitely for free space.  (was: 
I found an issue today on a broker when the temporary store was full and a 
non-persistent message was trying to be added to a durable subscription.  
Analysis showed that the broker was stuck in a loop trying to add the 
non-persistent message to the temporary store because the maxWaitTime value is 
not properly used inside of StoreDurableSubscriberCursor. Instead of honoring a 
timeout value and failing, instead the waitForSpace() method call on the 
temporary store was stuck in a loop waiting indefinitely for free space.)

> StoreDurableSubscriberCursor does not timeout properly on non-persistent 
> message send
> -
>
> Key: AMQ-6924
> URL: https://issues.apache.org/jira/browse/AMQ-6924
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.15.3
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 5.16.0, 5.15.4
>
>
> I found an issue today on a broker when the temporary store was full and a 
> non-persistent message was trying to be added to a durable subscription.  
> Analysis showed that the broker was stuck in a loop trying to add the 
> non-persistent message to the temporary store because the maxWaitTime value 
> is not properly used inside of StoreDurableSubscriberCursor. Instead of 
> honoring a timeout value and failing, the waitForSpace() method call on the 
> temporary store was stuck in a loop waiting indefinitely for free space.



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

[jira] [Created] (AMQ-6924) StoreDurableSubscriberCursor does not timeout properly on non-persistent message send

[Christopher L. Shannon (JIRA)]

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

 Summary: StoreDurableSubscriberCursor does not timeout properly on 
non-persistent message send
 Key: AMQ-6924
 URL: https://issues.apache.org/jira/browse/AMQ-6924
 Project: ActiveMQ
  Issue Type: Bug
  Components: Broker
Affects Versions: 5.15.3
Reporter: Christopher L. Shannon
Assignee: Christopher L. Shannon
 Fix For: 5.16.0, 5.15.4


I found an issue today on a broker when the temporary store was full and a 
non-persistent message was trying to be added to a durable subscription.  
Analysis showed that the broker was stuck in a loop trying to add the 
non-persistent message to the temporary store because the maxWaitTime value is 
not properly used inside of StoreDurableSubscriberCursor. Instead of honoring a 
timeout value and failing, instead the waitForSpace() method call on the 
temporary store was stuck in a loop waiting indefinitely for free space.



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

[jira] [Commented] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1741:
-

GitHub user andytaylor opened a pull request:

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

ARTEMIS-1741 - log warning if a node isnt configured for quorum voting

https://issues.apache.org/jira/browse/ARTEMIS-1741

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

$ git pull https://github.com/andytaylor/activemq-artemis master

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

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


commit 1d3082bf80f2d6cb2236280f3635e6afa5143e26
Author: andytaylor 
Date:   2018-03-09T10:19:34Z

ARTEMIS-1741 - log warning if a node isnt configured for quorum voting

https://issues.apache.org/jira/browse/ARTEMIS-1741




> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Updated] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[Andy Taylor (JIRA)]

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

Andy Taylor updated ARTEMIS-1741:
-
Fix Version/s: 2.5.0

> log warning if a node isnt configured for quorum voting
> ---
>
> Key: ARTEMIS-1741
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Andy Taylor
>Assignee: Andy Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Instead of throwing an exception



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

[jira] [Created] (ARTEMIS-1741) log warning if a node isnt configured for quorum voting

[Andy Taylor (JIRA)]

Andy Taylor created ARTEMIS-1741:


 Summary: log warning if a node isnt configured for quorum voting
 Key: ARTEMIS-1741
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1741
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Reporter: Andy Taylor
Assignee: Andy Taylor


Instead of throwing an exception



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