[jira] [Commented] (ARTEMIS-1631) Upgrade to Jolokia 1.4.0

[Lionel Cons (JIRA)]

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

Lionel Cons commented on ARTEMIS-1631:
--

Since 1.5.0 contains security fixes, what about upgrading Jolokia before 
Artemis 2.5.0 release?

> Upgrade to Jolokia 1.4.0
> 
>
> Key: ARTEMIS-1631
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1631
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Priority: Major
>




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

[jira] [Commented] (ARTEMIS-1714) Provide release summary & upgrade details

[Lionel Cons (JIRA)]

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

Lionel Cons commented on ARTEMIS-1714:
--

This is very good (and IMHO very useful). Thanks!

> Provide release summary & upgrade details
> -
>
> Key: ARTEMIS-1714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1714
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> It seems that there is only one place in the Artemis sources that contains 
> "release information". It is {{docs/README.md}} and the information there is 
> outdated since it only documents the releases 1.0.0, 1.1.0 and 1.2.0.
> Please keep the "release information" up to date with the new releases.
> It would probably make sense to put this information in the main GitBook 
> guide. A "release" or "changes" page listing all the versions with their 
> major changes (and a link to Jira for the complete list of changes) would be 
> very useful.
> FWIW, ActiveMQ has something similar at 
> http://activemq.apache.org/new-features.html. Kafka documents the "notable 
> changes", see for instance 
> https://kafka.apache.org/documentation/#upgrade_100_notable.



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

[jira] [Created] (ARTEMIS-1735) Getting Thread dump all of sudden while Artmis is running

[Dharmendra (JIRA)]

Dharmendra created ARTEMIS-1735:
---

 Summary: Getting Thread dump all of sudden while Artmis is running
 Key: ARTEMIS-1735
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1735
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.4.0
 Environment: Environment :  Linux box with Debian OS

Artemis 2.4.0 running with 1 GB memory
Reporter: Dharmendra
 Attachments: artemis.log, broker.xml

I simply deployed Artemis 2.4.0 on Test environment before final product 
release. Artemis was running smoothly but during night this thread dump 
occurred in warning. As such nothing special was running . That;s why i raised 
it in forum why such thread dump occurred all of sudden. I can not use Artemis 
2.5.0 because we are not going with version in production. Once Artmis 2.5.0 
will be released then we will upgrade. I am attaching complete thread dump and 
broker.xml file as per my configuration. Even system was running after getting 
thread dump as well but why this thread dump occured.PFA.



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

[jira] [Comment Edited] (ARTEMIS-1714) Provide release summary & upgrade details

[Justin Bertram (JIRA)]

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

Justin Bertram edited comment on ARTEMIS-1714 at 3/8/18 3:58 AM:
-

Thanks for clarifying. I like the idea of an executive summary, and we also 
need a place for version-specific upgrade details.  I sent a PR - 
https://github.com/apache/activemq-artemis/pull/1938.  Please review.


was (Author: jbertram):
Thanks for clarifying. I like the idea of an executive summary, and we also 
need a place for version-specific upgrade details.  I see a PR - 
https://github.com/apache/activemq-artemis/pull/1938.  Please review.

> Provide release summary & upgrade details
> -
>
> Key: ARTEMIS-1714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1714
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> It seems that there is only one place in the Artemis sources that contains 
> "release information". It is {{docs/README.md}} and the information there is 
> outdated since it only documents the releases 1.0.0, 1.1.0 and 1.2.0.
> Please keep the "release information" up to date with the new releases.
> It would probably make sense to put this information in the main GitBook 
> guide. A "release" or "changes" page listing all the versions with their 
> major changes (and a link to Jira for the complete list of changes) would be 
> very useful.
> FWIW, ActiveMQ has something similar at 
> http://activemq.apache.org/new-features.html. Kafka documents the "notable 
> changes", see for instance 
> https://kafka.apache.org/documentation/#upgrade_100_notable.



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

[jira] [Updated] (ARTEMIS-1714) Provide release summary & upgrade details

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1714:

Summary: Provide release summary & upgrade details  (was: The "release 
information" is out of date)

> Provide release summary & upgrade details
> -
>
> Key: ARTEMIS-1714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1714
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> It seems that there is only one place in the Artemis sources that contains 
> "release information". It is {{docs/README.md}} and the information there is 
> outdated since it only documents the releases 1.0.0, 1.1.0 and 1.2.0.
> Please keep the "release information" up to date with the new releases.
> It would probably make sense to put this information in the main GitBook 
> guide. A "release" or "changes" page listing all the versions with their 
> major changes (and a link to Jira for the complete list of changes) would be 
> very useful.
> FWIW, ActiveMQ has something similar at 
> http://activemq.apache.org/new-features.html. Kafka documents the "notable 
> changes", see for instance 
> https://kafka.apache.org/documentation/#upgrade_100_notable.



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

[jira] [Commented] (ARTEMIS-1714) The "release information" is out of date

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1714:
-

Thanks for clarifying. I like the idea of an executive summary, and we also 
need a place for version-specific upgrade details.  I see a PR - 
https://github.com/apache/activemq-artemis/pull/1938.  Please review.

> The "release information" is out of date
> 
>
> Key: ARTEMIS-1714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1714
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> It seems that there is only one place in the Artemis sources that contains 
> "release information". It is {{docs/README.md}} and the information there is 
> outdated since it only documents the releases 1.0.0, 1.1.0 and 1.2.0.
> Please keep the "release information" up to date with the new releases.
> It would probably make sense to put this information in the main GitBook 
> guide. A "release" or "changes" page listing all the versions with their 
> major changes (and a link to Jira for the complete list of changes) would be 
> very useful.
> FWIW, ActiveMQ has something similar at 
> http://activemq.apache.org/new-features.html. Kafka documents the "notable 
> changes", see for instance 
> https://kafka.apache.org/documentation/#upgrade_100_notable.



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

[jira] [Updated] (ARTEMIS-1714) The "release information" is out of date

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1714:

Fix Version/s: 2.5.0

> The "release information" is out of date
> 
>
> Key: ARTEMIS-1714
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1714
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Lionel Cons
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> It seems that there is only one place in the Artemis sources that contains 
> "release information". It is {{docs/README.md}} and the information there is 
> outdated since it only documents the releases 1.0.0, 1.1.0 and 1.2.0.
> Please keep the "release information" up to date with the new releases.
> It would probably make sense to put this information in the main GitBook 
> guide. A "release" or "changes" page listing all the versions with their 
> major changes (and a link to Jira for the complete list of changes) would be 
> very useful.
> FWIW, ActiveMQ has something similar at 
> http://activemq.apache.org/new-features.html. Kafka documents the "notable 
> changes", see for instance 
> https://kafka.apache.org/documentation/#upgrade_100_notable.



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

[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP

[Simon Chalmers (JIRA)]

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

Simon Chalmers commented on ARTEMIS-1709:
-

Great, thanks!

Confirmed with our simple test that it passes and the large message is now 
sent. We'll run some more tests over the next short while and see how it goes 
before updating this JIRA further.

> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single 
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result 
> in the same error and is sent successfully.
> Error:
>  
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on 
> the Server''s Session
>  at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
>  at 
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() 
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() 
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
>  task)
>  at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in 
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
>  task)
>  at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>  
>  



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

[jira] [Closed] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-1345.

Resolution: Fixed

> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> 

[jira] [Commented] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1345:
-

Github user asfgit closed the pull request at:

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


> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> 

[jira] [Commented] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1345 ConcurrentModificationException after copy


> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> 

[jira] [Commented] (ARTEMIS-1669) JMS message is not received when using a non-transactional JMSConnectionFactoryDefinition

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1669 Fixing test


> JMS message is not received when using a non-transactional 
> JMSConnectionFactoryDefinition
> -
>
> Key: ARTEMIS-1669
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1669
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.5.5
>Reporter: Jiri Ondrusek
>Priority: Major
> Fix For: 2.5.0
>
>
> When using a JMSConnectionFactoryDefinition annotation, and specifying a non 
> transactional connection factory, message is not being sent (or at least 
> received by MDB). Example:
> @JMSConnectionFactoryDefinition(
>  name = "java:app/jms/nonXAconnectionFactory",
>  transactional = false,
>  properties = {
>  "connectors=in-vm",}
>  ),
> When using an MDB message isn't received. Removing "transactional" attribute 
> makes it work again.



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

[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1286:
-

Let me clarify my previous comment:
* A reproducer is key.  I can't fix what I can't reproduce.
* Since the issue involves "direct" memory there may be non-obvious 
environmental related issues contributing to the problem (which may be why you 
can reproduce it and I can't).

Given you're receiving an {{OutOfDirectMemoryError}} I assume the the error is 
in fact related to a lack of memory - "direct" memory in particular.  Exactly 
how/why that's happening I can't say as I'm no expert on direct memory.

As I said previously, it's impossible for me to draw any firm conclusions at 
this point.

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: unscheduled
>
> Attachments: MQTTBasicPubSubExample2.zip, artemis log showing v2.4 
> still having trouble handling large messages.log, broker.xml, 
> image-2018-02-24-19-54-00-892.png, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 

[jira] [Commented] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1345:
-

GitHub user clebertsuconic opened a pull request:

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

ARTEMIS-1345 ConcurrentModificationException after copy



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

$ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-1345

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

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


commit 75501031b2076d00df3b7ec32cffa8e407a7e1f9
Author: Clebert Suconic 
Date:   2018-03-07T20:04:39Z

ARTEMIS-1345 ConcurrentModificationException after copy




> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> 

[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-1286:
--

You're still using the default global-max-size?

 

 

I will change the next version for a lower amount. but it's basically around 
the global-max-size.

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: unscheduled
>
> Attachments: MQTTBasicPubSubExample2.zip, artemis log showing v2.4 
> still having trouble handling large messages.log, broker.xml, 
> image-2018-02-24-19-54-00-892.png, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:828) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:616) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readBytes(ChannelBufferWrapper.java:315)
>  [artemis-commons-2.2.0-SNAPSHOT.jar:2.2.0-SNAPSHOT]
>   at 
> 

[jira] [Commented] (ARTEMIS-1286) Server stops responding and throws OutOfDirectMemoryError when sending & receiving lots of 2MB messages.

[Phillip Jenkins (JIRA)]

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

Phillip Jenkins commented on ARTEMIS-1286:
--

[~jbertram], let me see if I understand you. My Windows workstation with 16G of 
memory is running out of memory? I have little understanding of netty and no 
understanding of what causes the OODME. Are you saying that because it's a 
"direct memory error" it must be an issue with how much available free memory I 
have? Despite having gigabytes of available RAM sending 3MB messages will cause 
my to consume available memory? Please clarify. 

> Server stops responding and throws OutOfDirectMemoryError when sending & 
> receiving lots of 2MB messages.
> 
>
> Key: ARTEMIS-1286
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1286
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker, MQTT
>Affects Versions: 2.1.0
>Reporter: Phillip Jenkins
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: unscheduled
>
> Attachments: MQTTBasicPubSubExample2.zip, artemis log showing v2.4 
> still having trouble handling large messages.log, broker.xml, 
> image-2018-02-24-19-54-00-892.png, mqtt.zip
>
>
> Originally seen in v2.1 and present in v2.2.
> If you send and receive a lot of 2MB messages in short time thru Artemis via 
> Netty connector, the server throws the following OutOfDirectMemoryError 
> exception. The server stops responding and will not (any longer) accept 
> connections without throwing exceptions in an infinite loop.
> {code:java}
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241001: HTTP Server 
> started at http://localhost:8161
> 11:24:07,434 INFO  [org.apache.activemq.artemis] AMQ241002: Artemis Jolokia 
> REST API available at http://localhost:8161/jolokia
> 11:58:35,991 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, consumer=ServerConsumerImpl 
> [id=2229, filter=null, binding=LocalQueueBinding 
> [address=SOAP.S.PRN.ACBCAF6238234680, 
> queue=QueueImpl[name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=afa7de73-67e7-11e7-a231-54ee7505882d], 
> temp=false]@46adc2a5, filter=FilterImpl [sfilterString=NOT ((AMQAddress = 
> 'activemq.management') OR (AMQAddress = 'activemq.notifications'))], 
> name=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680, 
> clusterName=ACBCAF6238234680.SOAP.S.PRN.ACBCAF6238234680afa7de73-67e7-11e7-a231-54ee7505882d]],
>  
> message=Reference[3551]:NON-RELIABLE:CoreMessage[messageID=3551,durable=false,userID=null,priority=0,
>  timestamp=0,expiration=0, durable=false, 
> address=SOAP.S.PRN.ACBCAF6238234680,properties=TypedProperties[mqtt.message.retain=false,mqtt.qos.level=0]]@1305748199:
>  io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 3729415 
> byte(s) of direct memory (used: 1070952692, max: 1073741824)
>   at 
> io.netty.util.internal.PlatformDependent.incrementMemoryCounter(PlatformDependent.java:585)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.util.internal.PlatformDependent.allocateDirectNoCleaner(PlatformDependent.java:539)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledUnsafeNoCleanerDirectByteBuf.java:30)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.allocateDirect(UnpooledByteBufAllocator.java:169)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeDirectByteBuf.(UnpooledUnsafeDirectByteBuf.java:68)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledUnsafeNoCleanerDirectByteBuf.java:25)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeNoCleanerDirectByteBuf.(UnpooledByteBufAllocator.java:164)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:73)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:181)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 
> io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:117)
>  [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:828) 
> [netty-all-4.1.9.Final.jar:4.1.9.Final]
>   at 

[jira] [Created] (AMQ-6922) Review homepage design

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6922:
--

 Summary: Review homepage design
 Key: AMQ-6922
 URL: https://issues.apache.org/jira/browse/AMQ-6922
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Reopened] (ARTEMIS-17) Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5

[Justin Bertram (JIRA)]

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

Justin Bertram reopened ARTEMIS-17:
---

> Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5
> --
>
> Key: ARTEMIS-17
> URL: https://issues.apache.org/jira/browse/ARTEMIS-17
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Rob Davies
>Assignee: Andy Taylor
>Priority: Major
>
> One of the main reasons ActiveMQ is popular is its flexibility. Allowing 
> Camel to intercept messages inside the broker (Camel Broker Component) - will 
> allow some of the current BrokerPlugins (like TimeStamp) - to be implemented 
> using Camel routes.



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

[jira] [Updated] (ARTEMIS-17) Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-17:
--
Fix Version/s: (was: 2.0.0)

> Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5
> --
>
> Key: ARTEMIS-17
> URL: https://issues.apache.org/jira/browse/ARTEMIS-17
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Rob Davies
>Assignee: Andy Taylor
>Priority: Major
>
> One of the main reasons ActiveMQ is popular is its flexibility. Allowing 
> Camel to intercept messages inside the broker (Camel Broker Component) - will 
> allow some of the current BrokerPlugins (like TimeStamp) - to be implemented 
> using Camel routes.



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

[jira] [Closed] (ARTEMIS-17) Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5

[Justin Bertram (JIRA)]

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

Justin Bertram closed ARTEMIS-17.
-
Resolution: Duplicate

> Add Broker Interceptor - like the Camel Broker Component in ActiveMQ 5
> --
>
> Key: ARTEMIS-17
> URL: https://issues.apache.org/jira/browse/ARTEMIS-17
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Rob Davies
>Assignee: Andy Taylor
>Priority: Major
>
> One of the main reasons ActiveMQ is popular is its flexibility. Allowing 
> Camel to intercept messages inside the broker (Camel Broker Component) - will 
> allow some of the current BrokerPlugins (like TimeStamp) - to be implemented 
> using Camel routes.



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

[jira] [Created] (AMQ-6920) Generate pages for Community

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6920:
--

 Summary: Generate pages for Community
 Key: AMQ-6920
 URL: https://issues.apache.org/jira/browse/AMQ-6920
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6921) Generate pages for Team

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6921:
--

 Summary: Generate pages for Team
 Key: AMQ-6921
 URL: https://issues.apache.org/jira/browse/AMQ-6921
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6918) Generate pages for ActiveMQ

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6918:
--

 Summary: Generate pages for ActiveMQ
 Key: AMQ-6918
 URL: https://issues.apache.org/jira/browse/AMQ-6918
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6917) Generate pages for Clients

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6917:
--

 Summary: Generate pages for Clients
 Key: AMQ-6917
 URL: https://issues.apache.org/jira/browse/AMQ-6917
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6919) Generate pages for Artemis

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6919:
--

 Summary: Generate pages for Artemis
 Key: AMQ-6919
 URL: https://issues.apache.org/jira/browse/AMQ-6919
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6916) Ensure that all Metron references are removed

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6916:
--

 Summary: Ensure that all Metron references are removed
 Key: AMQ-6916
 URL: https://issues.apache.org/jira/browse/AMQ-6916
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Reopened] (ARTEMIS-473) Resolve split brain data after split brains scenarios.

[Justin Bertram (JIRA)]

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

Justin Bertram reopened ARTEMIS-473:


> Resolve split brain data after split brains scenarios.
> --
>
> Key: ARTEMIS-473
> URL: https://issues.apache.org/jira/browse/ARTEMIS-473
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Miroslav Novak
>Assignee: clebert suconic
>Priority: Critical
>
> If master-slave pair is configured using replicated journal and there are no 
> other servers in cluster then if network between master and slave is broken 
> then slave will activate. Depending on whether clients were disconnected from 
> master or not there might be or might not be failover to slave. Problem 
> happens in the moment when network between master and slave is restored. 
> Master and slave are active at the same time which is the split brain 
> syndrom. Currently there is no recovery mechanism to solve this situation.
> Suggested improvement: If clients failovered to slave then master will 
> restart itself so failback occurs (if configured). If clients did not 
> failover and stayed connected to master then backup will restart itself.



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

[jira] [Closed] (ARTEMIS-473) Resolve split brain data after split brains scenarios.

[Justin Bertram (JIRA)]

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

Justin Bertram closed ARTEMIS-473.
--
Resolution: Won't Fix

> Resolve split brain data after split brains scenarios.
> --
>
> Key: ARTEMIS-473
> URL: https://issues.apache.org/jira/browse/ARTEMIS-473
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Miroslav Novak
>Assignee: clebert suconic
>Priority: Critical
>
> If master-slave pair is configured using replicated journal and there are no 
> other servers in cluster then if network between master and slave is broken 
> then slave will activate. Depending on whether clients were disconnected from 
> master or not there might be or might not be failover to slave. Problem 
> happens in the moment when network between master and slave is restored. 
> Master and slave are active at the same time which is the split brain 
> syndrom. Currently there is no recovery mechanism to solve this situation.
> Suggested improvement: If clients failovered to slave then master will 
> restart itself so failback occurs (if configured). If clients did not 
> failover and stayed connected to master then backup will restart itself.



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

[jira] [Updated] (ARTEMIS-473) Resolve split brain data after split brains scenarios.

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-473:
---
Fix Version/s: (was: 1.5.0)

> Resolve split brain data after split brains scenarios.
> --
>
> Key: ARTEMIS-473
> URL: https://issues.apache.org/jira/browse/ARTEMIS-473
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Miroslav Novak
>Assignee: clebert suconic
>Priority: Critical
>
> If master-slave pair is configured using replicated journal and there are no 
> other servers in cluster then if network between master and slave is broken 
> then slave will activate. Depending on whether clients were disconnected from 
> master or not there might be or might not be failover to slave. Problem 
> happens in the moment when network between master and slave is restored. 
> Master and slave are active at the same time which is the split brain 
> syndrom. Currently there is no recovery mechanism to solve this situation.
> Suggested improvement: If clients failovered to slave then master will 
> restart itself so failback occurs (if configured). If clients did not 
> failover and stayed connected to master then backup will restart itself.



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

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

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated AMQ-6912:
---
Description: 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.  (was: Tracker Jira for website update.)

> 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] [Created] (AMQ-6915) Create gitbook for CMS

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6915:
--

 Summary: Create gitbook for CMS
 Key: AMQ-6915
 URL: https://issues.apache.org/jira/browse/AMQ-6915
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6914) Create gitbook for NMS

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6914:
--

 Summary: Create gitbook for NMS
 Key: AMQ-6914
 URL: https://issues.apache.org/jira/browse/AMQ-6914
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

[jira] [Created] (AMQ-6913) Manual check documentation that all links work and there are no formatting issues.

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6913:
--

 Summary: Manual check documentation that all links work and there 
are no formatting issues.
 Key: AMQ-6913
 URL: https://issues.apache.org/jira/browse/AMQ-6913
 Project: ActiveMQ
  Issue Type: Sub-task
Reporter: Martyn Taylor






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

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

[Martyn Taylor (JIRA)]

Martyn Taylor created AMQ-6912:
--

 Summary: Update website 
 Key: AMQ-6912
 URL: https://issues.apache.org/jira/browse/AMQ-6912
 Project: ActiveMQ
  Issue Type: Task
Reporter: Martyn Taylor


Tracker Jira for website update.



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

[jira] [Updated] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-1345:
-
Issue Type: Bug  (was: Test)

> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> 

[jira] [Updated] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-1345:
-
Fix Version/s: 2.5.0

> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> 

[jira] [Updated] (ARTEMIS-1345) Concurrent Modification Exceptions after Message.copy

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-1345:
-
Summary: Concurrent Modification Exceptions after Message.copy  (was: JMS 
tests in org.apache.activemq.artemis.tests.integration.jms.cluster are failing 
when run with AMQP protocol (qpid-jms-client JMS library))

> Concurrent Modification Exceptions after Message.copy
> -
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> 

[jira] [Reopened] (ARTEMIS-1345) JMS tests in org.apache.activemq.artemis.tests.integration.jms.cluster are failing when run with AMQP protocol (qpid-jms-client JMS library)

[clebert suconic (JIRA)]

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

clebert suconic reopened ARTEMIS-1345:
--
  Assignee: clebert suconic

> JMS tests in org.apache.activemq.artemis.tests.integration.jms.cluster are 
> failing when run with AMQP protocol (qpid-jms-client JMS library)
> 
>
> Key: ARTEMIS-1345
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1345
> Project: ActiveMQ Artemis
>  Issue Type: Test
>  Components: AMQP, Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: clebert suconic
>Priority: Major
>
> Consider tests
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.AutoCreateQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TemporaryQueueClusterTest}}
> {{org.apache.activemq.artemis.tests.integration.jms.cluster.TopicClusterTest}}
> When they are adapted to run through multiple JMS ConnectionFactories in 
> turn, these test are always passing with Core, one test method fails with 
> OpenWire (reported as ARTEMIS-1344), but all fail with AMQP.
> The broker prints the following error (every time)
> {noformat}
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,380 WARN  [org.apache.activemq.artemis.core.server] AMQ222151: 
> removing consumer which did not handle a message, 
> consumer=org.apache.activemq.artemis.core.server.cluster.impl.Redistributor@6c72718c,
>  
> message=Reference[28]:RELIABLE:org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage@799ad5a1:
>  java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209) [rt.jar:1.8.0_131]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:690)
>  [:]
>   at 
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage.putBytesProperty(AMQPMessage.java:743)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.addRouteContextToMessage(RemoteQueueBindingImpl.java:334)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.RemoteQueueBindingImpl.route(RemoteQueueBindingImpl.java:175)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.BindingsImpl.redistribute(BindingsImpl.java:222)
>  [:]
>   at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.redistribute(PostOfficeImpl.java:868)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.cluster.impl.Redistributor.handle(Redistributor.java:150)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:2802)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2187)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.ProcessorBase$ExecutorTask.run(ProcessorBase.java:53)
>  [:]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_131]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_131]
>   at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> [Thread-3 
> (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@18e36d14)]
>  10:30:51,381 ERROR [org.apache.activemq.artemis.core.server] AMQ224041: 
> Failed to deliver: java.util.NoSuchElementException
>   at 
> org.apache.activemq.artemis.utils.collections.PriorityLinkedListImpl$PriorityLinkedListIterator.repeat(PriorityLinkedListImpl.java:161)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2205)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$1900(QueueImpl.java:105)
>  [:]
>   at 
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:2994)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
>  [:]
>   at 
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
>  [:]
>   at 
> 

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

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1562:

Issue Type: Task  (was: Improvement)

> 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-1733) RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at startup

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1733:
-

For the initial connection the RoundRobinConnectionLoadBalancingPolicy can only 
work with what you give it so if you only provide a single server in your URL 
then there is only one to choose from when the initial connection is made.  
Once the initial connection is made then the client will receive the topology 
from the cluster so the next connection which is made will be to a different 
broker assuming you using the same ConnectionFactory or ServerLocator instance.

Here is an example of specifying multiple hosts in a single URL:

{{(tcp://myHost1:61616,tcp://myHost2:61616)?someUrlParameter=value}}

> RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at 
> startup
> ---
>
> Key: ARTEMIS-1733
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1733
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Laurent Bigonville
>Priority: Major
>
> Hi,
> When using the client-side-load-balancing from apache activemq artemis 
> examples on my own setup (2 RH amq) I see that the first connection is always 
> going to the same broker. The documentation says that 
> RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker 
> and then do round-robin, but that 1st step doesn't seems to work.
> I've the the following string in the jndi.properties and starting the example 
> with mvn -PnoServer verify:
> java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
> connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password
> queue.queue/exampleQueue=exampleQueue
> Adding some printnl() in the select() function of 
> RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
> RandomUtil.randomInterval(0, max); is being called with max value of 1 the 
> 1st time(should be 2 as there are two servers). The subsequent calls to that 
> functions show that max value is then set to 2 as expected.
> This explains why I always get my applications to connect to the same broker.



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

[jira] [Created] (ARTEMIS-1734) Unable to access to AMQ7.1 Management Console in read-only mode

[Jose Roman Martin Gil (JIRA)]

Jose Roman Martin Gil created ARTEMIS-1734:
--

 Summary: Unable to access to AMQ7.1 Management Console in 
read-only mode
 Key: ARTEMIS-1734
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1734
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Web Console
Affects Versions: 2.4.0
 Environment: RHEL 7.3

OpenJDK 1.8.0 (latest rpm)
Reporter: Jose Roman Martin Gil
 Attachments: amq-monitor-user.png

As administrator I want to create a monitor role to allow access to Management 
Console only to view and read the status of any objects.
 
As administrator I am using roles to manage queues and topics successfully but 
I would like to have users to monitor the broker with the Management Console.
 
At this moment I created a role and I updated the following files as: 
 
*etc/artemis.profile*: Changed the roles allowed to access:
{code:java}
-Dhawtio.roles=amq,monitor{code}
 
*etc/management.xml*: Allowed methods for each method:
{code:java}

 
 
 
 
 


 
 
 
 
 
 
 
{code}
With these changes I could login as monitor user however I found a lot of 
errors as:
 
{code:java}
ERROR: Insufficient roles/credentials for operation (class 
java.lang.SecurityException){code}
 



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

[jira] [Updated] (AMQ-6911) Constraint violation on failover (Postgresql)

[Maciej Miklas (JIRA)]

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

Maciej Miklas updated AMQ-6911:
---
Description: 
We have ActiveMq 5.15.2 in following configuration:
 * PostgreSQL for persistance
 * two nodes, one in standby
 * JDBC master slave with shared database
 * static cluster discovery

Everything seams to be fine, failover works as expected, but sometimes during 
failover we are observing following exception:
{code:java}
 28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
(7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 4, 
?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
existiert bereits.  Call getNextException to see other errors in the batch. 
   at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)  
      at 
org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
    at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
ActiveMQ propagates this exception directly to the client.

I am assuming, that due to a failover some clients did not get acknowledgment 
and message has been resent to a new node.

If I am correct ActiveMq should just ignore duplicated message, or both 
messages should be stored in database. But latest it's not possible, because  
ACTIVEMQ_MSGS#ID is a PK

 

  was:
We have ActiveMq 5.15.2 in following configuration:
 * PostgreSQL for persistance
 * two Nodes, one in Standby
 * JDBC Master Slave with shared Database
 * static cluster discovery

Everything seams to be fine, failover works as expected, but sometimes during 
failover we are observing following exception:
{code:java}
 28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
(7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 4, 
?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
existiert bereits.  Call getNextException to see other errors in the batch. 
   at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)  
      at 
org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
    at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
ActiveMQ propagates this exception directly to the client.

I am assuming, that due to a failover some clients did not get acknowledgment 
and message has been resent to a new node.

If I am correct ActiveMq should just ignore duplicated message, or both 
messages should be stored in database. But latest it's not possible, because  
ACTIVEMQ_MSGS#ID is a PK

 


> Constraint violation on failover (Postgresql)
> -
>
> Key: AMQ-6911
> URL: https://issues.apache.org/jira/browse/AMQ-6911
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.15.2
>Reporter: Maciej Miklas
>Priority: Major
>
> We have ActiveMq 5.15.2 in following configuration:
>  * PostgreSQL for persistance
>  * two nodes, one in standby
>  * JDBC master slave with shared database
>  * static cluster discovery
> Everything seams to be fine, failover works as expected, but sometimes during 
> failover we are observing following exception:
> {code:java}
>  28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
> org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
> FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
> MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
> (7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 
> 4, ?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
> Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel 

[jira] [Updated] (ARTEMIS-1733) RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at startup

[Laurent Bigonville (JIRA)]

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

Laurent Bigonville updated ARTEMIS-1733:

Description: 
Hi,

When using the client-side-load-balancing from apache activemq artemis examples 
on my own setup (2 RH amq) I see that the first connection is always going to 
the same broker. The documentation says that 
RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker and 
then do round-robin, but that 1st step doesn't seems to work.

I've the the following string in the jndi.properties and starting the example 
with mvn -PnoServer verify:

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password
queue.queue/exampleQueue=exampleQueue

Adding some printnl() in the select() function of 
RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
RandomUtil.randomInterval(0, max); is being called with max value of 1 the 1st 
time(should be 2 as there are two servers). The subsequent calls to that 
functions show that max value is then set to 2 as expected.

This explains why I always get my applications to connect to the same broker.

  was:
Hi,

When using the client-side-load-balancing from apache activemq artemis examples 
on my own setup (2 RH amq) I see that the first connection is always going to 
the same broker. The documentation says that 
RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker and 
then do round-robin, but that 1st step doesn't seems to work.

I've the the following string in the jndi.properties and starting the example 
with mvn -PnoServer verify:

{{java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory}}
{{ 
connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password}}
{{ queue.queue/exampleQueue=exampleQueue}}

Adding some printnl() in the select() function of 
RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
RandomUtil.randomInterval(0, max); is being called with max value of 1 the 1st 
time(should be 2 as there are two servers). The subsequent calls to that 
functions show that max value is then set to 2 as expected.

This explains why I always get my applications to connect to the same broker.


> RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at 
> startup
> ---
>
> Key: ARTEMIS-1733
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1733
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Laurent Bigonville
>Priority: Major
>
> Hi,
> When using the client-side-load-balancing from apache activemq artemis 
> examples on my own setup (2 RH amq) I see that the first connection is always 
> going to the same broker. The documentation says that 
> RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker 
> and then do round-robin, but that 1st step doesn't seems to work.
> I've the the following string in the jndi.properties and starting the example 
> with mvn -PnoServer verify:
> java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
> connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password
> queue.queue/exampleQueue=exampleQueue
> Adding some printnl() in the select() function of 
> RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
> RandomUtil.randomInterval(0, max); is being called with max value of 1 the 
> 1st time(should be 2 as there are two servers). The subsequent calls to that 
> functions show that max value is then set to 2 as expected.
> This explains why I always get my applications to connect to the same broker.



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

[jira] [Updated] (ARTEMIS-1733) RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at startup

[Laurent Bigonville (JIRA)]

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

Laurent Bigonville updated ARTEMIS-1733:

Description: 
Hi,

When using the client-side-load-balancing from apache activemq artemis examples 
on my own setup (2 RH amq) I see that the first connection is always going to 
the same broker. The documentation says that 
RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker and 
then do round-robin, but that 1st step doesn't seems to work.

I've the the following string in the jndi.properties and starting the example 
with mvn -PnoServer verify:

{{java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory}}
{{ 
connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password}}
{{ queue.queue/exampleQueue=exampleQueue}}

Adding some printnl() in the select() function of 
RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
RandomUtil.randomInterval(0, max); is being called with max value of 1 the 1st 
time(should be 2 as there are two servers). The subsequent calls to that 
functions show that max value is then set to 2 as expected.

This explains why I always get my applications to connect to the same broker.

  was:
Hi,

When using the client-side-load-balancing from apache activemq artemis examples 
on my own setup (2 RH amq) I see that the first connection is always going to 
the same broker. The documentation says that 
RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker and 
then do round-robin, but that 1st step doesn't seems to work.

I've the the following string in the jndi.properties and starting the example 
with mvn -PnoServer verify:

{{java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory}}

{{connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password}}

{{queue.queue/exampleQueue=exampleQueue}}

Adding some printnl() in the select() function of 
RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
RandomUtil.randomInterval(0, max); is being called with max value of 1 the 1st 
time(should be 2 as there are two servers). The subsequent calls to that 
functions show that max value is then set to 2 as expected.

This explains why I always get my applications to connect to the same broker.


> RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at 
> startup
> ---
>
> Key: ARTEMIS-1733
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1733
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Laurent Bigonville
>Priority: Major
>
> Hi,
> When using the client-side-load-balancing from apache activemq artemis 
> examples on my own setup (2 RH amq) I see that the first connection is always 
> going to the same broker. The documentation says that 
> RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker 
> and then do round-robin, but that 1st step doesn't seems to work.
> I've the the following string in the jndi.properties and starting the example 
> with mvn -PnoServer verify:
> {{java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory}}
> {{ 
> connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password}}
> {{ queue.queue/exampleQueue=exampleQueue}}
> Adding some printnl() in the select() function of 
> RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
> RandomUtil.randomInterval(0, max); is being called with max value of 1 the 
> 1st time(should be 2 as there are two servers). The subsequent calls to that 
> functions show that max value is then set to 2 as expected.
> This explains why I always get my applications to connect to the same broker.



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

[jira] [Created] (ARTEMIS-1733) RoundRobinConnectionLoadBalancingPolicy always connect to the 1st broker at startup

[Laurent Bigonville (JIRA)]

Laurent Bigonville created ARTEMIS-1733:
---

 Summary: RoundRobinConnectionLoadBalancingPolicy always connect to 
the 1st broker at startup
 Key: ARTEMIS-1733
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1733
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Laurent Bigonville


Hi,

When using the client-side-load-balancing from apache activemq artemis examples 
on my own setup (2 RH amq) I see that the first connection is always going to 
the same broker. The documentation says that 
RoundRobinConnectionLoadBalancingPolicy should 1st pick up a random broker and 
then do round-robin, but that 1st step doesn't seems to work.

I've the the following string in the jndi.properties and starting the example 
with mvn -PnoServer verify:

{{java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory}}

{{connectionFactory.ConnectionFactory=tcp://foo.example.com?user=user;password=password}}

{{queue.queue/exampleQueue=exampleQueue}}

Adding some printnl() in the select() function of 
RoundRobinConnectionLoadBalancingPolicy, I see that pos = 
RandomUtil.randomInterval(0, max); is being called with max value of 1 the 1st 
time(should be 2 as there are two servers). The subsequent calls to that 
functions show that max value is then set to 2 as expected.

This explains why I always get my applications to connect to the same broker.



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

[jira] [Updated] (AMQ-6911) Constraint violation on failover (Postgresql)

[Maciej Miklas (JIRA)]

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

Maciej Miklas updated AMQ-6911:
---
Affects Version/s: (was: 5.15.3)
   5.15.2

> Constraint violation on failover (Postgresql)
> -
>
> Key: AMQ-6911
> URL: https://issues.apache.org/jira/browse/AMQ-6911
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.15.2
>Reporter: Maciej Miklas
>Priority: Major
>
> We have ActiveMq 5.15.2 in following configuration:
>  * PostgreSQL for persistance
>  * two Nodes, one in Standby
>  * JDBC Master Slave with shared Database
>  * static cluster discovery
> Everything seams to be fine, failover works as expected, but sometimes during 
> failover we are observing following exception:
> {code:java}
>  28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
> org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
> FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
> MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
> (7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 
> 4, ?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
> Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
> existiert bereits.  Call getNextException to see other errors in the batch.   
>  at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)
>     at 
> org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
>     at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
> ActiveMQ propagates this exception directly to the client.
> I am assuming, that due to a failover some clients did not get acknowledgment 
> and message has been resent to a new node.
> If I am correct ActiveMq should just ignore duplicated message, or both 
> messages should be stored in database. But latest it's not possible, because  
> ACTIVEMQ_MSGS#ID is a PK
>  



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

[jira] [Commented] (AMQ-6911) Constraint violation on failover (Postgresql)

[Maciej Miklas (JIRA)]

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

Maciej Miklas commented on AMQ-6911:


sorry - that was typo - we have 5.15.2

> Constraint violation on failover (Postgresql)
> -
>
> Key: AMQ-6911
> URL: https://issues.apache.org/jira/browse/AMQ-6911
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.15.3
>Reporter: Maciej Miklas
>Priority: Major
>
> We have ActiveMq 5.12 in following configuration:
>  * PostgreSQL for persistance
>  * two Nodes, one in Standby
>  * JDBC Master Slave with shared Database
>  * static cluster discovery
> Everything seams to be fine, failover works as expected, but sometimes during 
> failover we are observing following exception:
> {code:java}
>  28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
> org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
> FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
> MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
> (7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 
> 4, ?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
> Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
> existiert bereits.  Call getNextException to see other errors in the batch.   
>  at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)
>     at 
> org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
>     at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
> ActiveMQ propagates this exception directly to the client.
> I am assuming, that due to a failover some clients did not get acknowledgment 
> and message has been resent to a new node.
> If I am correct ActiveMq should just ignore duplicated message, or both 
> messages should be stored in database. But latest it's not possible, because  
> ACTIVEMQ_MSGS#ID is a PK
>  



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

[jira] [Updated] (AMQ-6911) Constraint violation on failover (Postgresql)

[Maciej Miklas (JIRA)]

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

Maciej Miklas updated AMQ-6911:
---
Description: 
We have ActiveMq 5.15.2 in following configuration:
 * PostgreSQL for persistance
 * two Nodes, one in Standby
 * JDBC Master Slave with shared Database
 * static cluster discovery

Everything seams to be fine, failover works as expected, but sometimes during 
failover we are observing following exception:
{code:java}
 28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
(7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 4, 
?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
existiert bereits.  Call getNextException to see other errors in the batch. 
   at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)  
      at 
org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
    at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
ActiveMQ propagates this exception directly to the client.

I am assuming, that due to a failover some clients did not get acknowledgment 
and message has been resent to a new node.

If I am correct ActiveMq should just ignore duplicated message, or both 
messages should be stored in database. But latest it's not possible, because  
ACTIVEMQ_MSGS#ID is a PK

 

  was:
We have ActiveMq 5.12 in following configuration:
 * PostgreSQL for persistance
 * two Nodes, one in Standby
 * JDBC Master Slave with shared Database
 * static cluster discovery

Everything seams to be fine, failover works as expected, but sometimes during 
failover we are observing following exception:
{code:java}
 28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
(7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 4, 
?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
existiert bereits.  Call getNextException to see other errors in the batch. 
   at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)  
      at 
org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
    at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
ActiveMQ propagates this exception directly to the client.

I am assuming, that due to a failover some clients did not get acknowledgment 
and message has been resent to a new node.

If I am correct ActiveMq should just ignore duplicated message, or both 
messages should be stored in database. But latest it's not possible, because  
ACTIVEMQ_MSGS#ID is a PK

 


> Constraint violation on failover (Postgresql)
> -
>
> Key: AMQ-6911
> URL: https://issues.apache.org/jira/browse/AMQ-6911
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.15.3
>Reporter: Maciej Miklas
>Priority: Major
>
> We have ActiveMq 5.15.2 in following configuration:
>  * PostgreSQL for persistance
>  * two Nodes, one in Standby
>  * JDBC Master Slave with shared Database
>  * static cluster discovery
> Everything seams to be fine, failover works as expected, but sometimes during 
> failover we are observing following exception:
> {code:java}
>  28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
> org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
> FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
> MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
> (7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 
> 4, ?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
> Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 

[jira] [Commented] (AMQ-6911) Constraint violation on failover (Postgresql)

[Timothy Bish (JIRA)]

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

Timothy Bish commented on AMQ-6911:
---

5.12.x is an old release an not supported any longer, please upgrade to the 
latest version 5.15.3 and retest the scenario. 

> Constraint violation on failover (Postgresql)
> -
>
> Key: AMQ-6911
> URL: https://issues.apache.org/jira/browse/AMQ-6911
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 5.15.3
>Reporter: Maciej Miklas
>Priority: Major
>
> We have ActiveMq 5.12 in following configuration:
>  * PostgreSQL for persistance
>  * two Nodes, one in Standby
>  * JDBC Master Slave with shared Database
>  * static cluster discovery
> Everything seams to be fine, failover works as expected, but sometimes during 
> failover we are observing following exception:
> {code:java}
>  28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
> org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
> FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
> MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
> (7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 
> 4, ?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
> Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
> existiert bereits.  Call getNextException to see other errors in the batch.   
>  at 
> org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)
>     at 
> org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
>     at 
> org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
>     at 
> org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
> ActiveMQ propagates this exception directly to the client.
> I am assuming, that due to a failover some clients did not get acknowledgment 
> and message has been resent to a new node.
> If I am correct ActiveMq should just ignore duplicated message, or both 
> messages should be stored in database. But latest it's not possible, because  
> ACTIVEMQ_MSGS#ID is a PK
>  



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

[jira] [Created] (AMQ-6911) Constraint violation on failover (Postgresql)

[Maciej Miklas (JIRA)]

Maciej Miklas created AMQ-6911:
--

 Summary: Constraint violation on failover (Postgresql)
 Key: AMQ-6911
 URL: https://issues.apache.org/jira/browse/AMQ-6911
 Project: ActiveMQ
  Issue Type: Bug
  Components: JDBC
Affects Versions: 5.15.3
Reporter: Maciej Miklas


We have ActiveMq 5.12 in following configuration:
 * PostgreSQL for persistance
 * two Nodes, one in Standby
 * JDBC Master Slave with shared Database
 * static cluster discovery

Everything seams to be fine, failover works as expected, but sometimes during 
failover we are observing following exception:
{code:java}
 28.02.2018 09:28:54,207 WARN  [ActiveMQ NIO Worker 6] 
org.apache.activemq.transaction.LocalTransaction  - Store COMMIT 
FAILED:java.io.IOException: Batch entry 2 INSERT INTO ACTIVEMQ_MSGS(ID, 
MSGID_PROD, MSGID_SEQ, CONTAINER, EXPIRATION, PRIORITY, MSG, XID) VALUES 
(7095330, 'xxx-1-1519303952070-3:862:8:1', 15, 'queue://abc', 1520411334073, 4, 
?, NULL) was aborted: FEHLER: doppelter Schl▒sselwert verletzt 
Unique-Constraint ▒activemq_msgs_pkey▒  Detail: Schl▒ssel ▒(id)=(7095330)▒ 
existiert bereits.  Call getNextException to see other errors in the batch. 
   at 
org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:46)  
      at 
org.apache.activemq.store.jdbc.TransactionContext.commit(TransactionContext.java:209)
    at 
org.apache.activemq.store.jdbc.JDBCPersistenceAdapter.commitTransaction(JDBCPersistenceAdapter.java:516)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore$Tx.commit(MemoryTransactionStore.java:113)
    at 
org.apache.activemq.store.memory.MemoryTransactionStore.commit(MemoryTransactionStore.java:270){code}
ActiveMQ propagates this exception directly to the client.

I am assuming, that due to a failover some clients did not get acknowledgment 
and message has been resent to a new node.

If I am correct ActiveMq should just ignore duplicated message, or both 
messages should be stored in database. But latest it's not possible, because  
ACTIVEMQ_MSGS#ID is a PK

 



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

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

[Howard Gao (JIRA)]

Howard Gao created ARTEMIS-1732:
---

 Summary: 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
 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] [Assigned] (ARTEMIS-1341) Core JMS does not permit calling Message#getBytes(arbitrary type) when message has empty body

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1341:
---

Assignee: Stanislav Knot

> Core JMS does not permit calling Message#getBytes(arbitrary type) when 
> message has empty body
> -
>
> Key: ARTEMIS-1341
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1341
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.3.0
>Reporter: Jiri Daněk
>Assignee: Stanislav Knot
>Priority: Trivial
> Fix For: 2.5.0
>
>
> Consider the ActiveMQ Artemis test 
> {{org.apache.activemq.artemis.tests.integration.jms.jms2client.BodyTest#testBodyConversion}}
>  adapted to run through multiple JMS ConnectionFactories in turn. This test 
> passes with Core JMS client, is skipped (or should be skipped) with ActiveMQ 
> OpenWire client (that is a JMS 1.1 client) and fails with qpid-jms client.
> {noformat}
>  BytesMessage bytesMessage = sess.createBytesMessage();
>  producer.send(bytesMessage);
>  Message msg = cons.receiveNoWait();
>  assertNotNull(msg);
>  try {
> msg.getBody(String.class);
> fail("Exception expected");
>  } catch (MessageFormatException e) {
>  }
> {noformat}
> The test is wrong, see discussion with [~tabish121] at QPIDJMS-313 for 
> details and references as to why.



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

[jira] [Assigned] (ARTEMIS-1712) [openwire] missing null check could lead to NPE during TX rollback

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1712:
---

Assignee: Timothy Bish

> [openwire] missing null check could lead to NPE during TX rollback
> --
>
> Key: ARTEMIS-1712
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1712
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.4.0
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Minor
> Fix For: 2.5.0
>
>
> Code in OpenWireConnection that processes transaction rollback fails to check 
> that the TX provided is not null before trying to extract the session from 
> the protocol data which could lead to an NPE and circumvent all the later 
> checking that tries to handle that case such as a rollback when TX not 
> started case.



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

[jira] [Assigned] (ARTEMIS-1661) Enable splitting of broker.xml into multiple files

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1661:
---

Assignee: Michael Andre Pearce

> Enable splitting of broker.xml into multiple files
> --
>
> Key: ARTEMIS-1661
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1661
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Adi Rubin
>Assignee: Michael Andre Pearce
>Priority: Minor
> Fix For: 2.5.0
>
>
> Hi,
> Broker.xml contains both server configuration (connectors, cluster config 
> etc) and addresses/queues. It would be useful to be able to move the 
>  element to a separate file(s). An example use case would be 
> generation of addresses using a script.
> Ideally, this should apply to all configuration elements in broker.xml.



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

[jira] [Assigned] (ARTEMIS-1567) Roles in management configuration are hard coded. This may cause issues if the role is defined via CLI when the broker is created

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1567:
---

Assignee: Martyn Taylor

> Roles in management configuration are hard coded.   This may cause issues if 
> the role is defined via CLI when the broker is created
> ---
>
> Key: ARTEMIS-1567
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1567
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Assigned] (ARTEMIS-1550) Support LVQ for OpenWire

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1550:
---

Assignee: Michael Andre Pearce

> Support LVQ for OpenWire
> 
>
> Key: ARTEMIS-1550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1550
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> Currently over OpenWire, LVQ isn't supported, or honoured if an OpenWire 
> client produces to an address with an LVQueue.



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

[jira] [Assigned] (ARTEMIS-1495) Creating and destroying many queues could deadlock the broker

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1495:
---

Assignee: clebert suconic

> Creating and destroying many queues could deadlock the broker
> -
>
> Key: ARTEMIS-1495
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1495
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Reporter: Francesco Nigro
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
> Attachments: output.log
>
>
> Running a JMS test with 100 Producers/100Consumers/100 queues sending each 
> >=1 messages could lead the broker to deadlock while waiting the paging 
> cursor when the (core) clients disconnect (eg AMQ222022: Timed out waiting 
> for paging cursor to stop 
> FutureLatch(latch=java.util.concurrent.CountDownLatch@415d8105[Count = 1]) 
> OrderedExecutor(tasks=[FutureLatch(latch=java.util.concurrent.CountDownLatch@415d8105[Count
>  = 1])]))



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

[jira] [Assigned] (ARTEMIS-1581) limit non-ssl connection, handshake-timeout not configurable

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1581:
---

Assignee: Stanislav Knot

> limit non-ssl connection, handshake-timeout not configurable
> 
>
> Key: ARTEMIS-1581
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1581
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> "handshake-timeout" option for acceptor in broker.xml doesn't influence 
> actual time out. Connection is always cut after 10 seconds (default value) 
> regardless actual value configured.



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

[jira] [Assigned] (ARTEMIS-1606) Change AddressInfo RoutingType Set to use EnumSet

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1606:
---

Assignee: Michael Andre Pearce

> Change AddressInfo RoutingType Set to use EnumSet 
> --
>
> Key: ARTEMIS-1606
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1606
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> RoutingType is a enum, as such can take advantage of the benefits of EnumSet. 
> Its a specialist set designed for Enum's.
> https://docs.oracle.com/javase/7/docs/api/java/util/EnumSet.html
> https://www.techempower.com/blog/2017/02/14/enumset-and-enummap/
> This will reduce memory footprint due to being many times more compact, this 
> is particularly important as this Address Info and Routing Type sets are in 
> the hot path of message flow. And that there is only two routing types 
> currently so a very small enum.
> Also at the same time to remove the iterator from the getRoutingType which is 
> in the hotpath. Like wise we can avoid it if AddressInfo is constructed with 
> a single RoutingType.



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

[jira] [Assigned] (ARTEMIS-1612) Redistribution of messages does not work if prefixing is used

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1612:
---

Assignee: Martyn Taylor

> Redistribution of messages does not work if prefixing is used 
> --
>
> Key: ARTEMIS-1612
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1612
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> The problem lies in the redistribution logic, it uses the message address to 
> locate the bindings.  However, once the message has been routed, the original 
> "prefixless routing address" is not available.



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

[jira] [Assigned] (ARTEMIS-1508) AMQPMesage.reencode is broken

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1508:
---

Assignee: clebert suconic

> AMQPMesage.reencode is broken
> -
>
> Key: ARTEMIS-1508
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1508
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.5.0
>
>
> When a  is used to route messages from a topic to a queue, and when a 
> consumer attaches to the target queue using a selector expression, then no 
> messages are consumed, even though the message headers match the selector.
> In some (but not all) circumstances, an error message is seen in the broker 
> log:
> ~~~
> 08:57:44,807 ERROR [org.apache.activemq.artemis.core.server] AMQ224006: 
> Invalid filter: filename='XXX'
> ~~~



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

[jira] [Assigned] (ARTEMIS-1511) Add WebSocket coverage to STOMP tests

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1511:
---

Assignee: Martyn Taylor

> Add WebSocket coverage to STOMP tests
> -
>
> Key: ARTEMIS-1511
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1511
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Assigned] (ARTEMIS-1486) Core client should be notified if consumer is closed on broker side

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1486:
---

Assignee: Stanislav Knot

> Core client should be notified if consumer is closed on broker side
> ---
>
> Key: ARTEMIS-1486
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1486
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> If consumer is closed on broker using e.g. Hawtio console, client connected 
> as that consumer (representation of broker resource) should be notified about 
> that fact and react to that. It doesn't seem to react. If consumer is closed, 
> as a result of not being notified, client hangs in the air and cannot receive 
> messages.



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

[jira] [Assigned] (ARTEMIS-1580) Browsing in hawtio console allows to show empty pages

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1580:
---

Assignee: Stanislav Knot

> Browsing in hawtio console allows to show empty pages
> -
>
> Key: ARTEMIS-1580
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1580
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> Reproducer:
> 1. go to page, where you can browse pages (connections, addresses, etc..)
> 2. create for example 200 instances of displayed object
> 3. switch page size to min (50)
> 4. go to last page
> 5. switch page size to max (200)
> 6. go to previous page
> You are even allowed to be at _m-th_ page of _n_ pages, where _m > n_. 
> Possible fix is to add watcher to page and at every change put cursor to 
> first page. (as done 
> [here|https://github.com/apache/activemq-artemis/pull/1749/files#diff-0baae85e2b627a539716464c29c87b7eR119])



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

[jira] [Assigned] (ARTEMIS-1579) Browsing messages in hawtio management console is limited to 200 messages

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1579:
---

Assignee: Stanislav Knot

> Browsing messages in hawtio management console is limited to 200 messages
> -
>
> Key: ARTEMIS-1579
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1579
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> Browsing messages in hawtio management console is limited to 200 messages.
> With this, it is not possible to either page through all messages or change 
> the number of shown messages. 
> This limitation holds for both the Browse tab as well as the JMX browse() 
> operation.



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

[jira] [Assigned] (ARTEMIS-1659) AMQ224000: Failure in initialisation: java.lang.IllegalStateException: java.lang.IllegalStateException: Cursor 28 had already been created

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1659:
---

Assignee: Michael Andre Pearce

>  AMQ224000: Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> ---
>
> Key: ARTEMIS-1659
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1659
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.0.0
> Environment:  Artemis 2
>Reporter: Tom Ross
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> The following exception can be seen in the amq log file 
> {noformat}
> 08:07:04,658 ERROR [org.apache.activemq.artemis.core.server] AMQ224000: 
> Failure in initialisation: java.lang.IllegalStateException: 
> java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:151)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.PostOfficeJournalLoader.initQueues(PostOfficeJournalLoader.java:154)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.loadJournals(ActiveMQServerImpl.java:2481)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:2258)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:342)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$ActivationThread.run(ActiveMQServerImpl.java:2866)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> Caused by: java.lang.IllegalStateException: Cursor 28 had already been created
> at 
> org.apache.activemq.artemis.core.paging.cursor.impl.PageCursorProviderImpl.createSubscription(PageCursorProviderImpl.java:100)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> at 
> org.apache.activemq.artemis.core.server.QueueConfig$Builder.build(QueueConfig.java:149)
>  [artemis-server-2.0.0.amq-700013-redhat-1.jar:2.0.0.amq-700013-redhat-1]
> ... 5 more
> {noformat}



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

[jira] [Assigned] (ARTEMIS-1585) Log connector details on start

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1585:
---

Assignee: Michael Andre Pearce

> Log connector details on start
> --
>
> Key: ARTEMIS-1585
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1585
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> As like acceptors do, ensure details of connectors are logged out when they 
> start. This helps diagnose any issue with the clients later.



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

[jira] [Assigned] (ARTEMIS-1611) Artemis transformer interface is not backwards compatible

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1611:
---

Assignee: Martyn Taylor

> Artemis transformer interface is not backwards compatible
> -
>
> Key: ARTEMIS-1611
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1611
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.4.0
> Environment:  
>  
>Reporter: Jeff Mesnil
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> We have users of Artemis 1.x that uses the transformer interface defined in 
> org.apache.activemq.artemis.core.server.cluster.Transformer.
>  
> This class was moved in Artemis 2.x in an incompatible way: 
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/cluster/Transformer.java]
>  that redirects to 
> [https://github.com/apache/activemq-artemis/blob/master/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/transformer/Transformer.java]
> We are updating Artemis 2.x but it breaks the client configuration that was 
> using the old interface.
> We have strong requirement for backwards compatibility and we'd like to come 
> up with a solution so that the new interface could be made backwards 
> compatible with the existing one.
> Would it be possible sense to reintroduce the old interface in the 
> server.cluster package so that old code would still be able to run with 
> Artemis 2.x?
>  



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

[jira] [Assigned] (ARTEMIS-1658) Core queue lookup with Artemis RA no longer works with 1x address model

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1658:
---

Assignee: Martyn Taylor

> Core queue lookup with Artemis RA no longer works with 1x address model
> ---
>
> Key: ARTEMIS-1658
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1658
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.4.0
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> Artemis 1.x RA would do a core queue lookup if it could not find the
>  Destination in JNDI. We need to ensure that we can support the old
>  address model for backwards compatability.
>  



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

[jira] [Assigned] (ARTEMIS-1641) Cleanup eventual bad Page Transactions

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1641:
---

Assignee: clebert suconic

> Cleanup eventual bad Page Transactions
> --
>
> Key: ARTEMIS-1641
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1641
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>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] [Assigned] (ARTEMIS-1707) [openwire] error on create of queue if another connection creates one of the same name

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1707:
---

Assignee: Timothy Bish

> [openwire] error on create of queue if another connection creates one of the 
> same name
> --
>
> Key: ARTEMIS-1707
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1707
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 2.4.0
> Environment: OpenWire protocol head using ActiveMQ JMS client
>Reporter: Timothy Bish
>Assignee: Timothy Bish
>Priority: Major
> Fix For: 2.5.0
>
>
> When two OpenWire client resources (Producer or Consumer) attempt to create a 
> Queue destination (generally from two different connections) at the same time 
> the following exception can be seen:
> {noformat}
> java.lang.RuntimeException: javax.jms.JMSException: 
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018: 
> Binding already exists LocalQueueBinding [address=q2, 
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2], 
> temp=false]@6ca8009b, filter=null, name=q2, 
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
>     at net.ssorj.quiver.Client.run(QuiverArrowJms.java:126)
>     at net.ssorj.quiver.QuiverArrowJms.doMain(QuiverArrowJms.java:67)
>     at net.ssorj.quiver.QuiverArrowJms.main(QuiverArrowJms.java:29)
> Caused by: javax.jms.JMSException: 
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018: 
> Binding already exists LocalQueueBinding [address=q2, 
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2], 
> temp=false]@6ca8009b, filter=null, name=q2, 
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
>     at 
> org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:54)
>     at 
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1399)
>     at 
> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1428)
>     at 
> org.apache.activemq.ActiveMQSession.syncSendPacket(ActiveMQSession.java:2086)
>     at 
> org.apache.activemq.ActiveMQMessageProducer.(ActiveMQMessageProducer.java:124)
>     at 
> org.apache.activemq.ActiveMQSession.createProducer(ActiveMQSession.java:1117)
>     at net.ssorj.quiver.Client.sendMessages(QuiverArrowJms.java:136)
>     at net.ssorj.quiver.Client.run(QuiverArrowJms.java:113)
>     ... 2 more
> Caused by: java.lang.Throwable: 
> org.apache.activemq.artemis.api.core.ActiveMQQueueExistsException: AMQ119018: 
> Binding already exists LocalQueueBinding [address=q2, 
> queue=QueueImpl[name=q2, postOffice=PostOfficeImpl 
> [server=ActiveMQServerImpl::serverUUID=5e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2], 
> temp=false]@6ca8009b, filter=null, name=q2, 
> clusterName=q25e9fa4c0-1bf8-11e8-ada3-2c56dc3896a2]
>     at 
> org.apache.activemq.artemis.core.postoffice.impl.SimpleAddressManager.addBinding(SimpleAddressManager.java:85)
>     at 
> org.apache.activemq.artemis.core.postoffice.impl.WildcardAddressManager.addBinding(WildcardAddressManager.java:90)
>     at 
> org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl.addBinding(PostOfficeImpl.java:599)
>     at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2765)
>     at 
> org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676)
>     at 
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588)
>     at 
> org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:668)
>     at 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.addDestination(OpenWireConnection.java:768)
>     at 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection$CommandProcessor.processAddProducer(OpenWireConnection.java:1086)
>     at org.apache.activemq.command.ProducerInfo.visit(ProducerInfo.java:108)
>     at 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection.bufferReceived(OpenWireConnection.java:289)
>     at 
> org.apache.activemq.artemis.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:646)
>     at 
> org.apache.activemq.artemis.core.remoting.impl.netty.ActiveMQChannelHandler.channelRead(ActiveMQChannelHandler.java:68)
>     at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
>     at 
> 

[jira] [Assigned] (ARTEMIS-1625) Moving messages is broken

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1625:
---

Assignee: Stanislav Knot

> Moving messages is broken
> -
>
> Key: ARTEMIS-1625
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1625
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> Create address X
>  attach anycast queues A and B under address X
>  send message from A 
>  move message from A to B ( incorrect green notification appears ) 
>  check queues A and B, the message is not moved ... it is moved, but back to 
> queue A, itself.
>  try again to move message from A to B ( green notification ) 
>  message is moved



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

[jira] [Assigned] (ARTEMIS-1685) Set MQTT connection clientID before session creation

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1685:
---

Assignee: Dejan Bosanac

> Set MQTT connection clientID before session creation
> 
>
> Key: ARTEMIS-1685
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1685
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: MQTT
>Affects Versions: 2.4.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
>Priority: Major
> Fix For: 2.5.0
>
>
> It will make this property available in the plugin beforeCreateSession()  and 
> afterCreateSession(), which can be useful.



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

[jira] [Assigned] (ARTEMIS-1731) Startup fails when XSD validation cannot access Internet

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1731:
---

Assignee: Michael Andre Pearce

> Startup fails when XSD validation cannot access Internet
> 
>
> Key: ARTEMIS-1731
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1731
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Ilkka Virolainen
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> After a recent change allowing splitting up the broker configuration across 
> multiple files, starting Artemis fails when the server running broker has no 
> Internet access. xml:specialAttrs references in artemis-configuration.xsd 
> fail because the schema location http://www.w3.org/2005/08/xml.xsd is 
> inaccessible. To reproduce, pull the latest master for 2.5.0-SNAPSHOT, block 
> www.w3.org and try to run a broker. Including the schema in the build would 
> resolve this issue.



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

[jira] [Assigned] (ARTEMIS-1646) Browsing messages sent via JS client does not work

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1646:
---

Assignee: Stanislav Knot

> Browsing messages sent via JS client does not work
> --
>
> Key: ARTEMIS-1646
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1646
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
> Fix For: 2.5.0
>
>
> Trying to browse messages in hawtio console. Console gives this error message:
> javax.jms.MessageFormatException: class 
> org.apache.qpid.proton.amqp.UnsignedInteger is not a valid property type



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

[jira] [Assigned] (ARTEMIS-1632) Upgrade JBoss logging to 3.3.1.Final

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1632:
---

Assignee: Dejan Bosanac

> Upgrade JBoss logging to 3.3.1.Final
> 
>
> Key: ARTEMIS-1632
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1632
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 2.4.0
>Reporter: Dejan Bosanac
>Assignee: Dejan Bosanac
>Priority: Major
> Fix For: 2.5.0
>
>




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

[jira] [Assigned] (ARTEMIS-1512) Race Condition with STOMP Subscribe Receipt

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1512:
---

Assignee: Martyn Taylor

> Race Condition with STOMP Subscribe Receipt
> ---
>
> Key: ARTEMIS-1512
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1512
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Major
> Fix For: 2.5.0
>
>
> If a STOMP client sends a subscribe packet with receipt true, it can occur 
> that messages based on that subscription can arrive before the receipt.  This 
> can cause issues with STOMP clients.



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

[jira] [Assigned] (ARTEMIS-853) Support for exclusive consumers

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-853:
--

Assignee: Michael Andre Pearce  (was: Michael André Pearce)

> Support for exclusive consumers
> ---
>
> Key: ARTEMIS-853
> URL: https://issues.apache.org/jira/browse/ARTEMIS-853
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> Artemis should support a consumer feature where a single consumer receives 
> all messages, even when multiple consumers are present. This capability 
> maintains message ordering while allowing a HA consumer.
> ActiveMQ 5.x supports this, as does IBM MQ, Tibco EMS, etc.



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

[jira] [Assigned] (ARTEMIS-1569) Add 'user' attribute to queue in XML/JMX

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1569:
---

Assignee: Michael Andre Pearce  (was: Justin Bertram)

> Add 'user' attribute to queue in XML/JMX
> 
>
> Key: ARTEMIS-1569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1569
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> Currently a queue is tagged with the user who created it, if it is created 
> over the wire.
> This leaves out keeping audit of the user who may have created if declared in 
> broker.xml, as such should be possible to tag a queue with a user that would 
> be associated with creation.
> Also whilst this is exposed over the bespoke views for the console (new 
> panels), the attribute isn't exposed over JMX and is useful to capture.
> This JIRA is to implement both the ability to add a user tag to broker.xml to 
> associate the creator user, and like wise simply expose the extra attribute 
> in QueueControl JMX.



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

[jira] [Assigned] (ARTEMIS-1569) Add 'user' attribute to queue in XML/JMX

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1569:
---

Assignee: Justin Bertram

> Add 'user' attribute to queue in XML/JMX
> 
>
> Key: ARTEMIS-1569
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1569
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Michael Andre Pearce
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> Currently a queue is tagged with the user who created it, if it is created 
> over the wire.
> This leaves out keeping audit of the user who may have created if declared in 
> broker.xml, as such should be possible to tag a queue with a user that would 
> be associated with creation.
> Also whilst this is exposed over the bespoke views for the console (new 
> panels), the attribute isn't exposed over JMX and is useful to capture.
> This JIRA is to implement both the ability to add a user tag to broker.xml to 
> associate the creator user, and like wise simply expose the extra attribute 
> in QueueControl JMX.



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

[jira] [Assigned] (ARTEMIS-853) Support for exclusive consumers

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-853:
--

Assignee: Michael André Pearce

> Support for exclusive consumers
> ---
>
> Key: ARTEMIS-853
> URL: https://issues.apache.org/jira/browse/ARTEMIS-853
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
>Assignee: Michael André Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> Artemis should support a consumer feature where a single consumer receives 
> all messages, even when multiple consumers are present. This capability 
> maintains message ordering while allowing a HA consumer.
> ActiveMQ 5.x supports this, as does IBM MQ, Tibco EMS, etc.



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

[jira] [Assigned] (ARTEMIS-1571) Upgrade to Netty 4.1.19.Final

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1571:
---

Assignee: Michael Andre Pearce  (was: Justin Bertram)

> Upgrade to Netty 4.1.19.Final
> -
>
> Key: ARTEMIS-1571
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1571
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Michael Andre Pearce
>Assignee: Michael Andre Pearce
>Priority: Major
> Fix For: 2.5.0
>
>
> There is a critical issue found and announced in 4.1.18 which is fixed in 
> 4.1.19
> http://netty.io/news/2017/12/18/4-1-19-Final.html



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

[jira] [Assigned] (ARTEMIS-1571) Upgrade to Netty 4.1.19.Final

[Justin Bertram (JIRA)]

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

Justin Bertram reassigned ARTEMIS-1571:
---

Assignee: Justin Bertram

> Upgrade to Netty 4.1.19.Final
> -
>
> Key: ARTEMIS-1571
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1571
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Michael Andre Pearce
>Assignee: Justin Bertram
>Priority: Major
> Fix For: 2.5.0
>
>
> There is a critical issue found and announced in 4.1.18 which is fixed in 
> 4.1.19
> http://netty.io/news/2017/12/18/4-1-19-Final.html



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

[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1709:
-

I noted this in IRC when we chatted last night.  Look in 
{{artemis-distribution/target}}.  Specifically, the binary distribution will be 
in the {{apache-artemis-2.5.0-SNAPSHOT-bin}} directory.

> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single 
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result 
> in the same error and is sent successfully.
> Error:
>  
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on 
> the Server''s Session
>  at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
>  at 
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() 
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() 
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
>  task)
>  at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in 
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging 
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
>  — End of stack trace from previous location where exception was thrown —
>  at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
>  at 
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
>  task)
>  at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>  
>  



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

[jira] [Commented] (ARTEMIS-1653) Allow database tables to be created externally

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1653:
-

Github user nlippke commented on a diff in the pull request:

https://github.com/apache/activemq-artemis/pull/1822#discussion_r172812406
  
--- Diff: 
artemis-jdbc-store/src/main/java/org/apache/activemq/artemis/jdbc/store/drivers/AbstractJDBCDriver.java
 ---
@@ -109,7 +109,7 @@ public void stop() throws SQLException {
protected abstract void createSchema() throws SQLException;
 
protected final void createTable(String... schemaSqls) throws 
SQLException {
-  createTableIfNotExists(connection, sqlProvider.getTableName(), 
schemaSqls);
+  createTableIfNotExists(sqlProvider.getTableName(), schemaSqls);
--- End diff --

`createTableIfNotExists` was `private static` before. I needed to change it 
to non-static in order for `TestJDBCDriver` to be able to access the underlying 
connection to create the empty table for the test.


> Allow database tables to be created externally
> --
>
> Key: ARTEMIS-1653
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1653
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.4.0
>Reporter: Niels Lippke
>Priority: Major
>
> In some environments (e.g. production) it is not allowed that applications 
> create their own schema. It's common practice to pass DDL-Statetements to 
> DBAs instead prior to rollout.
> Currently the broker does not support this scenario. If the required tables 
> already exist the broker fails to start.
> A better approach is that if the broker detects empy tables and initializes 
> them in the very same way it does if the tables dont't exist.
> See also discussion in 
> [forum|http://activemq.2283324.n4.nabble.com/ARTEMIS-Server-doesn-t-start-if-JDBC-store-is-used-and-table-NODE-MANAGER-STORE-is-empty-td4735779.html].



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

[jira] [Resolved] (ARTEMIS-1715) Disable to remove a divert from hawtio console

[Stanislav Knot (JIRA)]

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

Stanislav Knot resolved ARTEMIS-1715.
-
Resolution: Fixed

> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



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

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/1913
  
@clebertsuconic yup, looks better, i've merged.


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



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

[jira] [Commented] (ARTEMIS-1715) Disable to remove a divert from hawtio console

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1715:
-

Github user asfgit closed the pull request at:

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


> Disable to remove a divert from hawtio console
> --
>
> Key: ARTEMIS-1715
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1715
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Removing divert is broken (broker tries to remove diverted address, not 
> divert itself). It should be disabled to remove divert.



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