[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf commented on ARTEMIS-550:
---

Just to add a last note. I think Virtual Topics even support the usage of 
queues and subscription (anycast and multicast) in parallel on the same topic. 
I don't know if this scenario is actually really used but it exists!

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARTEMIS-826) MQTT with a long password field causes NPE exception

[Martyn Taylor (JIRA)]

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

Martyn Taylor reassigned ARTEMIS-826:
-

Assignee: Martyn Taylor

> MQTT with a long password field causes NPE exception
> 
>
> Key: ARTEMIS-826
> URL: https://issues.apache.org/jira/browse/ARTEMIS-826
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0, 1.5.0
>Reporter: luca capra
>Assignee: Martyn Taylor
>Priority: Critical
>  Labels: mqtt
> Fix For: 2.next
>
>
> Hi
> I'm using mqtt.js and Paho (java) as client for MQTT protocol. 
> The issue can be replicated both on (my embed) version pointing at master 
> (1.5.0-SNAPSHOT) and with a clean install of 1.4.0 release
> Happens by using a long password (a jwt token in my case) which causes this 
> exception on both versions
> Example password:
> eyJhbGciOiJIUzUxMiJ9.eyJjcmVhdGVkIjoxNDc3NDg1NDc5OTEzLCJleHAiOjE0Nzc0ODcyNzksInV1aWQiOiI2NmVkNDc3Mi0wNDg5LTRlOTYtYmI2NS01NDhiMmVkMmM3MWQifQ.LbOAr8pPApDlVBLi32JWtCjmCa80ByAJYq9BnTnWQgh4SWka4WzykMU0D_atE5tYtgICj2QOg-OFglv2ZqLLNw
> Exception:
> Caused by: java.lang.NullPointerException
>   at 
> org.apache.activemq.artemis.core.protocol.ProtocolHandler$ProtocolDecoder.decode(ProtocolHandler.java:185)
>  [artemis-server-1.4.0.jar:1.4.0]
> Looking at the source Artemis receive a different set of bytes ("M"QTT starts 
> at array[5])
> https://github.com/apache/activemq-artemis/blob/master/artemis-protocols/artemis-mqtt-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/mqtt/MQTTProtocolManager.java#L131
> ---
> MQTT spec on password length (0 to 65535 bytes of binary data + 2bytes for 
> length)
> http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Toc385349246
> Client code is here:
> https://gist.github.com/muka/df7cac712a645b9f1895274adcbe3670
> Embed artemis code is here:
> https://github.com/muka/raptor/tree/master/raptor-broker
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARTEMIS-806) Publishing a MQTT message on one node of the cluster is not distributed to the subscriber on a different node when using topic pattern expression.

[Martyn Taylor (JIRA)]

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

Martyn Taylor reassigned ARTEMIS-806:
-

Assignee: Martyn Taylor

> Publishing a MQTT message on one node of the cluster is not distributed to 
> the subscriber on a different node when using topic pattern expression.
> --
>
> Key: ARTEMIS-806
> URL: https://issues.apache.org/jira/browse/ARTEMIS-806
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.4.0
>Reporter: Antoine Toulme
>Assignee: Martyn Taylor
>
> We are trying out ActiveMQ Artemis with MQTT. We are interested in using 
> pattern subscription such as foo/# to listen to a set of topics.
> We created a cluster in which one client publishes to a node, while an other 
> one subscribes to another.
> When using pattern subscriptions, we see that the subscriber does not receive 
> the message.
> When using an exact subscription (foo/bar), the subscriber receives the 
> message.
> I have managed to reproduce the issue by adjusting the symmetric cluster 
> example.
> Here is the code:
> https://github.com/atoulme/activemq-artemis/tree/mqtt_cluster_test2
> With this code, I see that messages are sent, but none are received.
> If you change the subscription to “mqtt/bar” line 71 and 103, messages are 
> passed OK.
> More context here:
> http://mail-archives.apache.org/mod_mbox/activemq-dev/201610.mbox/%3CC5A6C1AC-C985-4F30-AF4D-0E5F27E69D2B%40gmail.com%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1031) Prefixes no longer working with Core Client

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1031:
-

Github user asfgit closed the pull request at:

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


> Prefixes no longer working with Core Client
> ---
>
> Key: ARTEMIS-1031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1031
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1031) Prefixes no longer working with Core Client

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1031 Fix prefix support


> Prefixes no longer working with Core Client
> ---
>
> Key: ARTEMIS-1031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1031
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1031) Prefixes no longer working with Core Client

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1031:
-

Github user mtaylor commented on the issue:

https://github.com/apache/activemq-artemis/pull/1087
  
@clebertsuconic This removes a bunch of code you added to strip prefix from 
the address.  Was there a reason to do this?  We don't change the send address 
for prefixes.  Client will receive "multicast://foo" for example.  We add the 
proper address to the RoutingContext but leave the message as is.


> Prefixes no longer working with Core Client
> ---
>
> Key: ARTEMIS-1031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1031
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1031) Prefixes no longer working with Core Client

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1031:
-

GitHub user mtaylor opened a pull request:

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

ARTEMIS-1031 Fix prefix support



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

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

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

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


commit dd067409e8f2d3c495e976212f41796bdae470cf
Author: Martyn Taylor 
Date:   2017-03-10T17:35:51Z

ARTEMIS-1031 Fix prefix support




> Prefixes no longer working with Core Client
> ---
>
> Key: ARTEMIS-1031
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1031
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Martyn Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMQ-6624) ActiveMQ Web Console 5.14.x doesn't work with Tomcat 7.0.65

[Nikola Radic (JIRA)]

Nikola Radic created AMQ-6624:
-

 Summary: ActiveMQ Web Console 5.14.x doesn't work with Tomcat 
7.0.65
 Key: AMQ-6624
 URL: https://issues.apache.org/jira/browse/AMQ-6624
 Project: ActiveMQ
  Issue Type: Bug
  Components: webconsole
Affects Versions: 5.14.4, 5.14.3
 Environment: Tomcat 7.0.65, JDK 1.8_66
Reporter: Nikola Radic
Priority: Minor


Running activemq-web-console-5.14.3.war under Tomcat gives the following error 
when accessing home page:

SEVERE: Servlet.service() for servlet [jsp] in context with path [/jms] threw 
exception [/index.jsp (line: 1, column: 1) The absolute uri: 
http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the 
jar files deployed with this application] with root cause
org.apache.jasper.JasperException: /index.jsp (line: 1, column: 1) The absolute 
uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or 
the jar files deployed with this application

The same error appear for 5.14.4 as well as nightly build 
activemq-web-console-5.15.0-20170309.041201-70.war.

The last working version was 5.11.1.
==
The cause is missing TLD jars, *javax.servlet.jstl_1.1.2.jar* and 
*taglibs.standard_1.1.2.jar*.

I noticed that last commit in Web Console GIT repo possibly resolves the issue, 
but haven't tried to build from source.

==
The workround:

- added Maven dependencies
- copied dependencies under WEB-INF/lib using  *maven-dependency-plugin*


org.apache.maven.plugins
maven-dependency-plugin


copy-missing-jars
prepare-package


copy-dependencies



${project.build.directory}/${project.build.finalName}/WEB-INF/lib

jstl,
standard







The web console is started using tomcat7-maven-plugin.





--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf commented on ARTEMIS-550:
---

The alias feature looks fine to me. I think that should work for me once it's 
done.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor edited comment on ARTEMIS-550 at 3/10/17 4:07 PM:


Another thing to note.  You don't have to switch on VirtualTopics for certain 
addresses.  The virtual topic feature maps to just creation of queues in 
Artemis.  The architecture in Artemis is different to ActiveMQ.  We actually 
don't have topics, we deal only with addresses and queues.  A topic 
subscription in Artemis is just a queue bound to an address with multicast 
routing type, which essentially just means that the queue receives a copy of 
each message sent it's address.

Normally the protocol managers take care of creating subscription queues on 
behalf of the clients.  All that is happening here is that you are bypassing 
the protocol manager and directly creating your own subscription queue.


was (Author: martyntaylor):
Another thing to note.  You don't have to switch on VirtualTopics for certain 
addresses.  The virtual topic feature maps to just creation of queues in 
Artemis.  The architecture in Artemis is different to ActiveMQ.  We actually 
don't have topics, we deal only with addresses in queues.  A topic subscription 
in Artemis is just a queue bound to an address with multicast routing type, 
which essentially just means that the queue receives a copy of each message 
sent it's address.

Normally the protocol managers take care of creating subscription queues on 
behalf of the clients.  All that is happening here is that you are bypassing 
the protocol manager and directly creating your own subscription queue.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor edited comment on ARTEMIS-550 at 3/10/17 4:08 PM:


Another thing to note.  You don't have to switch on VirtualTopics for certain 
addresses.  The virtual topic feature maps to just creation of queues in 
Artemis.  The architecture in Artemis is different to ActiveMQ.  We actually 
don't have topics, we deal only with addresses and queues.  A topic 
subscription in Artemis is just a queue bound to an address with multicast 
routing type, which essentially just means that the queue receives a copy of 
each message sent it's address.

Normally the protocol managers take care of creating subscription queues on 
behalf of the clients.  All that is happening when you use "FQQN" or "Aliasing 
in this case" is that you are bypassing the protocol manager and directly 
creating your own subscription queue.


was (Author: martyntaylor):
Another thing to note.  You don't have to switch on VirtualTopics for certain 
addresses.  The virtual topic feature maps to just creation of queues in 
Artemis.  The architecture in Artemis is different to ActiveMQ.  We actually 
don't have topics, we deal only with addresses and queues.  A topic 
subscription in Artemis is just a queue bound to an address with multicast 
routing type, which essentially just means that the queue receives a copy of 
each message sent it's address.

Normally the protocol managers take care of creating subscription queues on 
behalf of the clients.  All that is happening here is that you are bypassing 
the protocol manager and directly creating your own subscription queue.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor commented on ARTEMIS-550:
---

Another thing to note.  You don't have to switch on VirtualTopics for certain 
addresses.  The virtual topic feature maps to just creation of queues in 
Artemis.  The architecture in Artemis is different to ActiveMQ.  We actually 
don't have topics, we deal only with addresses in queues.  A topic subscription 
in Artemis is just a queue bound to an address with multicast routing type, 
which essentially just means that the queue receives a copy of each message 
sent it's address.

Normally the protocol managers take care of creating subscription queues on 
behalf of the clients.  All that is happening here is that you are bypassing 
the protocol manager and directly creating your own subscription queue.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor edited comment on ARTEMIS-550 at 3/10/17 4:02 PM:


The idea was to do this with aliasing, to match the 5.x naming scheme onto 
Artemis.  The Aliasing feature hasn't been fully fleshed out, but off the top 
of my head something the following:

{code:title=broker.xml|borderStyle=solid}
 // Match all addresses
 
  // Apply the alias when the address starts with Consumer
  
  
  
  // Apply the alias when the address starts with Consumer
  
  
   Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor edited comment on ARTEMIS-550 at 3/10/17 4:02 PM:


The idea was to do this with aliasing, to match the 5.x naming scheme onto 
Artemis.  The Aliasing feature hasn't been fully fleshed out, but off the top 
of my head something the following:

{code:title=broker.xml|borderStyle=solid}
 
  // Apply the alias when the address starts with Consumer
  
  
  
  // Apply the alias when the address starts with Consumer
  
  
   Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor commented on ARTEMIS-550:
---

The idea was to do this with aliasing, to match the 5.x naming scheme onto 
Artemis.  The Aliasing feature hasn't been fully fleshed out, but off the top 
of my head something the following:

// Match all addresses that start with VirtualTopic
 // Match all addresses
 
  // Apply the alias when the address starts with Consumer
  
  
   Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6623) update to proton-j 0.18.0

[ASF subversion and git services (JIRA)]

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

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

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

AMQ-6623: update to proton-j 0.18.0


> update to proton-j 0.18.0
> -
>
> Key: AMQ-6623
> URL: https://issues.apache.org/jira/browse/AMQ-6623
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: AMQP
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 5.15.0
>
>
> update to proton-j 0.18.0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (AMQ-6623) update to proton-j 0.18.0

[Robbie Gemmell (JIRA)]

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

Robbie Gemmell resolved AMQ-6623.
-
Resolution: Fixed

> update to proton-j 0.18.0
> -
>
> Key: AMQ-6623
> URL: https://issues.apache.org/jira/browse/AMQ-6623
> Project: ActiveMQ
>  Issue Type: Improvement
>  Components: AMQP
>Reporter: Robbie Gemmell
>Assignee: Robbie Gemmell
>Priority: Minor
> Fix For: 5.15.0
>
>
> update to proton-j 0.18.0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (AMQ-6623) update to proton-j 0.18.0

[Robbie Gemmell (JIRA)]

Robbie Gemmell created AMQ-6623:
---

 Summary: update to proton-j 0.18.0
 Key: AMQ-6623
 URL: https://issues.apache.org/jira/browse/AMQ-6623
 Project: ActiveMQ
  Issue Type: Improvement
  Components: AMQP
Reporter: Robbie Gemmell
Assignee: Robbie Gemmell
Priority: Minor
 Fix For: 5.15.0


update to proton-j 0.18.0



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6620) Creating queue and sending message don't work from Webconsole in Karaf

[ASF subversion and git services (JIRA)]

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

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

Commit dea1accb9882b2db45000da93f2506d07bd15089 in activemq's branch 
refs/heads/activemq-5.14.x from [~ch...@die-schneider.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=dea1acc ]

[AMQ-6620] Workaround until the actual issue is fixed in karaf


> Creating queue and sending message don't work from Webconsole in Karaf
> --
>
> Key: AMQ-6620
> URL: https://issues.apache.org/jira/browse/AMQ-6620
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.14.4
> Environment: Java 8
>Reporter: Xilai Dai
>Assignee: Christian Schneider
> Attachments: queue.png
>
>
> Steps to reproduce this issue:
> 1) start Karaf 4.1.0 (also change "127.0.0.1" to "0.0.0.0" in the 
> etc/org.apache.karaf.management.cfg to make sure remove JMX working)
> 2) install Activemq broker and webconsole into karaf
> feature:repo-add activemq 5.14.4
> feature:install activemq-broker
> 3) open http://localhost:8181/activemqweb/ from a Browser, try to create a 
> Queue and send message to this queue from UI
> Then the Name of the queue couldn't be shown on the page and consequently the 
> "Send To" page doesn't work.
> (The Standalong AMQ 5.14.4 Webconsle works well as expected)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6620) Creating queue and sending message don't work from Webconsole in Karaf

[ASF subversion and git services (JIRA)]

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

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

Commit f651aa361f8d8428c94420d1f5713c70ed0baf07 in activemq's branch 
refs/heads/master from [~ch...@die-schneider.net]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=f651aa3 ]

[AMQ-6620] Workaround until the actual issue is fixed in karaf


> Creating queue and sending message don't work from Webconsole in Karaf
> --
>
> Key: AMQ-6620
> URL: https://issues.apache.org/jira/browse/AMQ-6620
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: webconsole
>Affects Versions: 5.14.4
> Environment: Java 8
>Reporter: Xilai Dai
>Assignee: Christian Schneider
> Attachments: queue.png
>
>
> Steps to reproduce this issue:
> 1) start Karaf 4.1.0 (also change "127.0.0.1" to "0.0.0.0" in the 
> etc/org.apache.karaf.management.cfg to make sure remove JMX working)
> 2) install Activemq broker and webconsole into karaf
> feature:repo-add activemq 5.14.4
> feature:install activemq-broker
> 3) open http://localhost:8181/activemqweb/ from a Browser, try to create a 
> Queue and send message to this queue from UI
> Then the Name of the queue couldn't be shown on the page and consequently the 
> "Send To" page doesn't work.
> (The Standalong AMQ 5.14.4 Webconsle works well as expected)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (AMQ-6622) Unmatched acknowledge: MessageAckExpected - message count (1) differs from count in dispatched-list (2)

[Abhi (JIRA)]

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

Abhi commented on AMQ-6622:
---

I have tried to reproduce it but it seems very hard. I found an old post on 
activemq user forum that faced a similar issue - 
.http://activemq.2283324.n4.nabble.com/Unmatched-acknowledge-td2955542.html.



> Unmatched acknowledge: MessageAckExpected -  message count (1) differs from 
> count in dispatched-list (2)
> 
>
> Key: AMQ-6622
> URL: https://issues.apache.org/jira/browse/AMQ-6622
> Project: ActiveMQ
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 5.14.4
> Environment: ActiveMQ v5.14.4, Linux, STOMP consumer
>Reporter: Abhi
>
> Observed below exceptions in STOMP consumer after failover.
> The consumer continued to receive messages but this exception kept coming and 
> when the master activemq instance took over after another failover, all the 
> messages were redelivered and below warning went away.
> Exception:
> [20170310 00:24:22:092 stomp_client.py:82 ERROR] Received an error: 
> org.apache.activemq.transport.stomp.ProtocolException: Unexpected ACK 
> received for message-id 
> [ID:diogenes31.nyc.deshaw.com-41001-1489085659582-1:4:-1:1:1]
>     at 
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompAck(ProtocolConverter.java:475)
>     at 
> org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:250)
>     at 
> org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
>     at 
> org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
>     at 
> org.apache.activemq.transport.stomp.StompCodec.processCommand(StompCodec.java:129)
>     at 
> org.apache.activemq.transport.stomp.StompCodec.parse(StompCodec.java:100)
>     at 
> org.apache.activemq.transport.stomp.StompNIOTransport.processBuffer(StompNIOTransport.java:136)
>     at 
> org.apache.activemq.transport.stomp.StompNIOTransport.serviceRead(StompNIOTransport.java:121)
>     at 
> org.apache.activemq.transport.stomp.StompNIOTransport.access$000(StompNIOTransport.java:44)
>     at 
> org.apache.activemq.transport.stomp.StompNIOTransport$1.onSelect(StompNIOTransport.java:73)
>     at 
> org.apache.activemq.transport.nio.SelectorSelection.onSelect(SelectorSelection.java:98)
>     at 
> org.apache.activemq.transport.nio.SelectorWorker$1.run(SelectorWorker.java:118)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>     at java.lang.Thread.run(Thread.java:745)
>  
> [20170310 00:24:22:096 stomp_client.py:82 ERROR] Received an error: 
> javax.jms.JMSException: Unmatched acknowledge: MessageAck {commandId = 5, 
> responseRequired = false, ackType = 2, consumerId = 
> ID:diogenes31.nyc.deshaw.com-41001-1489085659582-1:9:-1:1, firstMessageId = 
> null, lastMessageId = 
> ID:diogenes31.nyc.deshaw.com-41001-1489085659582-1:4:-1:1:2, destination = 
> topic://run1.topic.0, transactionId = null, messageCount = 1, poisonCause = 
> null}; Expected message count (1) differs from count in dispatched-list (2)
>     at 
> org.apache.activemq.broker.region.PrefetchSubscription.assertAckMatchesDispatched(PrefetchSubscription.java:520)
>     at 
> org.apache.activemq.broker.region.PrefetchSubscription.acknowledge(PrefetchSubscription.java:212)
>     at 
> org.apache.activemq.broker.region.AbstractRegion.acknowledge(AbstractRegion.java:528)
>     at 
> org.apache.activemq.broker.region.RegionBroker.acknowledge(RegionBroker.java:484)
>     at 
> org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:88)
>     at 
> org.apache.activemq.broker.TransactionBroker.acknowledge(TransactionBroker.java:276)
>     at 
> org.apache.activemq.broker.BrokerFilter.acknowledge(BrokerFilter.java:88)
>     at 
> org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:98)
>     at 
> org.apache.activemq.broker.util.LoggingBrokerPlugin.acknowledge(LoggingBrokerPlugin.java:162)
>     at 
> org.apache.activemq.broker.MutableBrokerFilter.acknowledge(MutableBrokerFilter.java:98)
>     at 
> deshaw.tools.jms.ActiveMQLoggingPlugin.acknowledge(ActiveM

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf commented on ARTEMIS-550:
---

Still the same question.

How to configure
{code}{code}
in Artemis in the future? 

That's my most urgent example. :-)

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor commented on ARTEMIS-550:
---

There will be differences in the configuration.  

If you use the Artemis scheme i.e. FQQN, you don't need to configure anything.  
You probably want to lock down the broker using security settings but actually 
out of the box, you can do the main thing that virtual topics offers you, 
shared subscriptions, queue control etc...

We do also want to ensure that users migrating to Artemis from ActiveMQ 5.x 
have an appropriate migration path.  Part of that is adding the ability to 
support the ActiveMQ 5.x virtual topic naming scheme, so that users do not have 
to update client applications.  There will be a way to do this though it may be 
more than 1 line in the configuration.

I've changed the JIRA to not include OpenWire (it's in fact a issue that should 
be resolved across all protocols).  If you could add specific examples of what 
you require to the JIRA we can address them when we come to implementing the 
features.

Cheers

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-1030) Support equivilent ActiveMQ 5.x Virtual Topic Naming Abilities

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-1030:
---
Summary: Support equivilent ActiveMQ 5.x Virtual Topic Naming Abilities  
(was: Support ActiveMQ 5.x Virtual Topic Naming Scheme for OpenWire)

> Support equivilent ActiveMQ 5.x Virtual Topic Naming Abilities
> --
>
> Key: ARTEMIS-1030
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1030
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Martyn Taylor
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-1011) Slow consumer detection - producer msg/s rate for queue should take into account messages which are already in queue

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-1011:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Slow consumer detection - producer msg/s rate for queue should take into 
> account messages which are already in queue
> 
>
> Key: ARTEMIS-1011
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1011
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.5.5, 2.next
>
>
> There is still a problem how producer msg/s rate is calculated in 
> {{QueueImpl.getRate()}} for slow consumer detection. It calculates only 
> messages added during the last slow consumer check period. As this is used to 
> figure out, in which msg/s rate the queue could serve the consumer then it 
> should also take into account messages which are already in queue at the 
> start of queueRateCheckTime period. 
> Current implementation is problem for cases when messages are sent to queue 
> in bursts, for example producer sends 1000s messages in a few seconds and 
> then stops and will do that again in 1 hour. QueueImpl.getRate() method 
> returns 0 msg/s for slow consumer check period set to for example 5 min and 
> slow consumer detection will be skipped. 
> I tried to fix it by following change to QueueImpl.getRate() method and seems 
> to be ok, wdyt?
> {code}
>private final AtomicLong messageCountSnapshot = new AtomicLong(0);
>public float getRate() {
>   long locaMessageAdded = getMessagesAdded();
>   float timeSlice = ((System.currentTimeMillis() - 
> queueRateCheckTime.getAndSet(System.currentTimeMillis())) / 1000.0f);
>   if (timeSlice == 0) {
>  messagesAddedSnapshot.getAndSet(locaMessageAdded);
>  return 0.0f;
>   }
>   return BigDecimal.valueOf(((locaMessageAdded - 
> messagesAddedSnapshot.getAndSet(locaMessageAdded)) + 
> messageCountSnapshot.getAndSet(getMessageCount())) / timeSlice).setScale(2, 
> BigDecimal.ROUND_UP).floatValue();
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (ARTEMIS-1011) Slow consumer detection - producer msg/s rate for queue should take into account messages which are already in queue

[clebert suconic (JIRA)]

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

clebert suconic reopened ARTEMIS-1011:
--

> Slow consumer detection - producer msg/s rate for queue should take into 
> account messages which are already in queue
> 
>
> Key: ARTEMIS-1011
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1011
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.5.5, 2.next
>
>
> There is still a problem how producer msg/s rate is calculated in 
> {{QueueImpl.getRate()}} for slow consumer detection. It calculates only 
> messages added during the last slow consumer check period. As this is used to 
> figure out, in which msg/s rate the queue could serve the consumer then it 
> should also take into account messages which are already in queue at the 
> start of queueRateCheckTime period. 
> Current implementation is problem for cases when messages are sent to queue 
> in bursts, for example producer sends 1000s messages in a few seconds and 
> then stops and will do that again in 1 hour. QueueImpl.getRate() method 
> returns 0 msg/s for slow consumer check period set to for example 5 min and 
> slow consumer detection will be skipped. 
> I tried to fix it by following change to QueueImpl.getRate() method and seems 
> to be ok, wdyt?
> {code}
>private final AtomicLong messageCountSnapshot = new AtomicLong(0);
>public float getRate() {
>   long locaMessageAdded = getMessagesAdded();
>   float timeSlice = ((System.currentTimeMillis() - 
> queueRateCheckTime.getAndSet(System.currentTimeMillis())) / 1000.0f);
>   if (timeSlice == 0) {
>  messagesAddedSnapshot.getAndSet(locaMessageAdded);
>  return 0.0f;
>   }
>   return BigDecimal.valueOf(((locaMessageAdded - 
> messagesAddedSnapshot.getAndSet(locaMessageAdded)) + 
> messageCountSnapshot.getAndSet(getMessageCount())) / timeSlice).setScale(2, 
> BigDecimal.ROUND_UP).floatValue();
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1011) Slow consumer detection - producer msg/s rate for queue should take into account messages which are already in queue

[ASF subversion and git services (JIRA)]

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

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

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

Revert "ARTEMIS-1011 Small adjustment on test"
Revert "ARTEMIS-1011 adjust slow-consumer detection logic"

This reverts commit 9818206bd3aa893864eedf06d19d0c2d5c355a9c.
This reverts commit 19ebbfb5f0a10daca6f2f516efae4755613254fd.


> Slow consumer detection - producer msg/s rate for queue should take into 
> account messages which are already in queue
> 
>
> Key: ARTEMIS-1011
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1011
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.5.5, 2.0.0
>
>
> There is still a problem how producer msg/s rate is calculated in 
> {{QueueImpl.getRate()}} for slow consumer detection. It calculates only 
> messages added during the last slow consumer check period. As this is used to 
> figure out, in which msg/s rate the queue could serve the consumer then it 
> should also take into account messages which are already in queue at the 
> start of queueRateCheckTime period. 
> Current implementation is problem for cases when messages are sent to queue 
> in bursts, for example producer sends 1000s messages in a few seconds and 
> then stops and will do that again in 1 hour. QueueImpl.getRate() method 
> returns 0 msg/s for slow consumer check period set to for example 5 min and 
> slow consumer detection will be skipped. 
> I tried to fix it by following change to QueueImpl.getRate() method and seems 
> to be ok, wdyt?
> {code}
>private final AtomicLong messageCountSnapshot = new AtomicLong(0);
>public float getRate() {
>   long locaMessageAdded = getMessagesAdded();
>   float timeSlice = ((System.currentTimeMillis() - 
> queueRateCheckTime.getAndSet(System.currentTimeMillis())) / 1000.0f);
>   if (timeSlice == 0) {
>  messagesAddedSnapshot.getAndSet(locaMessageAdded);
>  return 0.0f;
>   }
>   return BigDecimal.valueOf(((locaMessageAdded - 
> messagesAddedSnapshot.getAndSet(locaMessageAdded)) + 
> messageCountSnapshot.getAndSet(getMessageCount())) / timeSlice).setScale(2, 
> BigDecimal.ROUND_UP).floatValue();
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-1011) Slow consumer detection - producer msg/s rate for queue should take into account messages which are already in queue

[ASF subversion and git services (JIRA)]

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

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

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

Revert "ARTEMIS-1011 Small adjustment on test"
Revert "ARTEMIS-1011 adjust slow-consumer detection logic"

This reverts commit 9818206bd3aa893864eedf06d19d0c2d5c355a9c.
This reverts commit 19ebbfb5f0a10daca6f2f516efae4755613254fd.


> Slow consumer detection - producer msg/s rate for queue should take into 
> account messages which are already in queue
> 
>
> Key: ARTEMIS-1011
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1011
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Miroslav Novak
>Assignee: Justin Bertram
> Fix For: 1.5.5, 2.0.0
>
>
> There is still a problem how producer msg/s rate is calculated in 
> {{QueueImpl.getRate()}} for slow consumer detection. It calculates only 
> messages added during the last slow consumer check period. As this is used to 
> figure out, in which msg/s rate the queue could serve the consumer then it 
> should also take into account messages which are already in queue at the 
> start of queueRateCheckTime period. 
> Current implementation is problem for cases when messages are sent to queue 
> in bursts, for example producer sends 1000s messages in a few seconds and 
> then stops and will do that again in 1 hour. QueueImpl.getRate() method 
> returns 0 msg/s for slow consumer check period set to for example 5 min and 
> slow consumer detection will be skipped. 
> I tried to fix it by following change to QueueImpl.getRate() method and seems 
> to be ok, wdyt?
> {code}
>private final AtomicLong messageCountSnapshot = new AtomicLong(0);
>public float getRate() {
>   long locaMessageAdded = getMessagesAdded();
>   float timeSlice = ((System.currentTimeMillis() - 
> queueRateCheckTime.getAndSet(System.currentTimeMillis())) / 1000.0f);
>   if (timeSlice == 0) {
>  messagesAddedSnapshot.getAndSet(locaMessageAdded);
>  return 0.0f;
>   }
>   return BigDecimal.valueOf(((locaMessageAdded - 
> messagesAddedSnapshot.getAndSet(locaMessageAdded)) + 
> messageCountSnapshot.getAndSet(getMessageCount())) / timeSlice).setScale(2, 
> BigDecimal.ROUND_UP).floatValue();
>}
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf edited comment on ARTEMIS-550 at 3/10/17 2:19 PM:


[~martyntaylor]]

Well, if virtual topics will not be supported the way it is supported actually 
that would be disappointing to many users IMHO. One big benefit is that you can 
configure it with just one line in the broker configuration and you have dozens 
topic to queue combinations addressed for now an for the future. It's only 
about naming pattern. I don't think this gap can be closed with an OpenWire 
modification.


was (Author: graben):
[~mtaylor]

Well, if virtual topics will not be supported the way it is supported actually 
that would be disappointing to many users IMHO. One big benefit is that you can 
configure it with just one line in the broker configuration and you have dozens 
topic to queue combinations addressed for now an for the future. It's only 
about naming pattern. I don't think this gap can be closed with an OpenWire 
modification.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf edited comment on ARTEMIS-550 at 3/10/17 2:19 PM:


[~martyntaylor]

Well, if virtual topics will not be supported the way it is supported actually 
that would be disappointing to many users IMHO. One big benefit is that you can 
configure it with just one line in the broker configuration and you have dozens 
topic to queue combinations addressed for now an for the future. It's only 
about naming pattern. I don't think this gap can be closed with an OpenWire 
modification.


was (Author: graben):
[~martyntaylor]]

Well, if virtual topics will not be supported the way it is supported actually 
that would be disappointing to many users IMHO. One big benefit is that you can 
configure it with just one line in the broker configuration and you have dozens 
topic to queue combinations addressed for now an for the future. It's only 
about naming pattern. I don't think this gap can be closed with an OpenWire 
modification.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf commented on ARTEMIS-550:
---

[~mtaylor]

Well, if virtual topics will not be supported the way it is supported actually 
that would be disappointing to many users IMHO. One big benefit is that you can 
configure it with just one line in the broker configuration and you have dozens 
topic to queue combinations addressed for now an for the future. It's only 
about naming pattern. I don't think this gap can be closed with an OpenWire 
modification.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-24) Lazy conversions on Protocols / Persistency

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-24:
---
Fix Version/s: (was: 2.next)
   2.0.0

> Lazy conversions on Protocols / Persistency
> ---
>
> Key: ARTEMIS-24
> URL: https://issues.apache.org/jira/browse/ARTEMIS-24
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
> Fix For: 2.0.0
>
>
> We should do like apollo on converting between Protocols and persisting data. 
> We should keep the data native as much as we can to the protocol and only 
> convert when needed.
> Right now we are always converting to an internal format independently of the 
> protocol.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-24) Lazy conversions on Protocols / Persistency

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-24.
--
Resolution: Fixed

> Lazy conversions on Protocols / Persistency
> ---
>
> Key: ARTEMIS-24
> URL: https://issues.apache.org/jira/browse/ARTEMIS-24
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
> Fix For: 2.0.0
>
>
> We should do like apollo on converting between Protocols and persisting data. 
> We should keep the data native as much as we can to the protocol and only 
> convert when needed.
> Right now we are always converting to an internal format independently of the 
> protocol.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-566) Cannot remove JMS queue that has been removed from Core side

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-566.
---
   Resolution: Fixed
Fix Version/s: (was: 2.next)
   2.0.0

This is not an issue on 2.0.0 with the simplified address model.

> Cannot remove JMS queue that has been removed from Core side
> 
>
> Key: ARTEMIS-566
> URL: https://issues.apache.org/jira/browse/ARTEMIS-566
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>Priority: Minor
> Fix For: 2.0.0
>
>
> If a queue that has been created from the JMS side is removed from the Core 
> side in JMX, a phantom JMS queue is left behind which cannot be removed.
> 1) Start jconsole, connect to artemis
> 2) Navigate in mbeans to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> 
> JMS -> Server -> Operations
> 3) Invoke createQueue TestQueue
> 4) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core, note 
> that jms.queue.TestQueue is in both Address and Queue
> 5) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core -> 
> Server -> Operations
> 6) Invoke destroyQueue TestQueue
> 7) Note that jms.queue.TestQueue disappears from Address and Queue from 
> org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core (as expected)
> 8) Navigate to Navigate in mbeans to org.apache.activemq.artemis -> Broker -> 
> 0.0.0.0 -> JMS -> Queue
> 9) Note that TestQueue is still listed
> 10) Try to remove it with destroyQueue TestQueue from 
> org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> JMS -> Server -> 
> Operations
> 11) Get ActiveMQNonExistentQueueException, and the queue is not removed
> A workaround is to restart artemis, that results in the Core side queue 
> becoming visible again, and then step 10) succeeds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-829) Core Protocol Producers will re-encode messages on the server

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-829:

Fix Version/s: (was: 2.next)
   2.0.0

> Core Protocol Producers will re-encode messages on the server
> -
>
> Key: ARTEMIS-829
> URL: https://issues.apache.org/jira/browse/ARTEMIS-829
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.0.0
>
>
> In an attempt to optimize small message producers, the producer will remove 
> the address from the message and re-encode it on the server. that will make 
> Netty to double the size, and remove the former buffer, what will generate 
> more memory throughput for the same mesage.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-829) Core Protocol Producers will re-encode messages on the server

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-829.
---
Resolution: Fixed

> Core Protocol Producers will re-encode messages on the server
> -
>
> Key: ARTEMIS-829
> URL: https://issues.apache.org/jira/browse/ARTEMIS-829
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.0.0
>
>
> In an attempt to optimize small message producers, the producer will remove 
> the address from the message and re-encode it on the server. that will make 
> Netty to double the size, and remove the former buffer, what will generate 
> more memory throughput for the same mesage.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-169) Fix imported open wire tests

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-169.
---
   Resolution: Not A Problem
Fix Version/s: (was: 2.next)

> Fix imported open wire tests
> 
>
> Key: ARTEMIS-169
> URL: https://issues.apache.org/jira/browse/ARTEMIS-169
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: clebert suconic
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-213) Fix WireFormatNegotiationTest

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-213.
---
   Resolution: Not A Problem
Fix Version/s: (was: 2.next)

> Fix WireFormatNegotiationTest
> -
>
> Key: ARTEMIS-213
> URL: https://issues.apache.org/jira/browse/ARTEMIS-213
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
>Assignee: clebert suconic
>
> Client can negotiate a working wireformat version with broker. If a client 
> requests a earlier version of wireformat the broker should respect it. e.g.
> if a client request:
> "tcp://localhost:61616?wireFormat.version=1"
> The server should confirm that the version to be used is 1.
> Test: WireformatNegociationTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Martyn Taylor (JIRA)]

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

Martyn Taylor commented on ARTEMIS-550:
---

[~graben] 

Are you saying that it is not possible to implement these things using the new 
address model?  I agree that the existing naming conventions i.e. using "::" is 
different to ActiveMQ 5.x, and there are gaps wrt how things are configured.  
For example using prefixing.  The JIRA I added above is intended to track gap 
in the naming schema, like for example using prefixes instead of FQQN.

What I don't want to do, is just clone the way ActiveMQ 5.x does virtual 
topics, as it doesn't fit in well with the Artemis architecture.  Instead, I 
plan on providing generic solutions for things like address aliasing that solve 
part of the problem, whilst being an overall useful feature for other use cases.

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-173) Document migration path for all activemq5 features

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-173:
-

[~martyntaylor] / [~dejanb] isn't this done?

> Document migration path for all activemq5 features
> --
>
> Key: ARTEMIS-173
> URL: https://issues.apache.org/jira/browse/ARTEMIS-173
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: clebert suconic
>Priority: Critical
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-164) Add examples from qpid JMS

[clebert suconic (JIRA)]

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

clebert suconic closed ARTEMIS-164.
---
   Resolution: Fixed
Fix Version/s: (was: 2.next)
   2.0.0

I have added some amqp examples... I think that's it

> Add examples from qpid JMS
> --
>
> Key: ARTEMIS-164
> URL: https://issues.apache.org/jira/browse/ARTEMIS-164
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Minor
> Fix For: 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (ARTEMIS-164) Add examples from qpid JMS

[clebert suconic (JIRA)]

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

clebert suconic reassigned ARTEMIS-164:
---

Assignee: clebert suconic  (was: Justin Bertram)

> Add examples from qpid JMS
> --
>
> Key: ARTEMIS-164
> URL: https://issues.apache.org/jira/browse/ARTEMIS-164
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Minor
> Fix For: 2.0.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-164) Add examples from qpid JMS

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-164:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Add examples from qpid JMS
> --
>
> Key: ARTEMIS-164
> URL: https://issues.apache.org/jira/browse/ARTEMIS-164
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: clebert suconic
>Assignee: Justin Bertram
>Priority: Minor
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[clebert suconic (JIRA)]

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

clebert suconic 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
> Fix For: 1.5.0
>
>
> 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
(v6.3.15#6346)

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

[clebert suconic (JIRA)]

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

clebert suconic commented on ARTEMIS-473:
-

[~martyntaylor] this is unfixable. We can only avoid split brains... 

this feature was a request to fix the journal after a split brain...  After the 
data is mixed.. there's no way to differentiate it.

you can only configure the system to avoid it.

> 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
> Fix For: 1.5.0
>
>
> 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
(v6.3.15#6346)

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

[clebert suconic (JIRA)]

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

clebert suconic updated ARTEMIS-473:

Fix Version/s: (was: 2.next)
   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
> Fix For: 1.5.0
>
>
> 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
(v6.3.15#6346)

[jira] [Commented] (ARTEMIS-550) Add support for virtual topic consumers

[Benjamin Graf (JIRA)]

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

Benjamin Graf commented on ARTEMIS-550:
---

I'm not sure if the new addressing model really supports the naming pattern 
schema of virtual topics in total. Maybe you can post an example configuration 
for an ActiveMQ 5.x use case like 

> Add support for virtual topic consumers
> ---
>
> Key: ARTEMIS-550
> URL: https://issues.apache.org/jira/browse/ARTEMIS-550
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Benjamin Graf
>Assignee: Martyn Taylor
>
> Artemis should support virtual topic consumers as alternative to topic 
> subscriptions as ActiveMQ itself does.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-375) When use ./artemis data exp, the xml printed to stdout mixed with logging information

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-375:
--
Fix Version/s: (was: 2.0.0)
   2.next

> When use ./artemis data exp, the xml printed to stdout mixed with logging 
> information
> -
>
> Key: ARTEMIS-375
> URL: https://issues.apache.org/jira/browse/ARTEMIS-375
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0
>Reporter: Howard Nguyen
> Fix For: 2.next
>
> Attachments: XmlDataExport-improvement.patch
>
>
> When use ./artemis data exp, the xml printed to stdout mixed with logging 
> information.
> Attached patch.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-213) Fix WireFormatNegotiationTest

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-213:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix WireFormatNegotiationTest
> -
>
> Key: ARTEMIS-213
> URL: https://issues.apache.org/jira/browse/ARTEMIS-213
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
>Assignee: clebert suconic
> Fix For: 2.next
>
>
> Client can negotiate a working wireformat version with broker. If a client 
> requests a earlier version of wireformat the broker should respect it. e.g.
> if a client request:
> "tcp://localhost:61616?wireFormat.version=1"
> The server should confirm that the version to be used is 1.
> Test: WireformatNegociationTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-184) Fix openwire tests under org.apache.activemq.transport.tcp package

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-184:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix openwire tests under org.apache.activemq.transport.tcp package
> --
>
> Key: ARTEMIS-184
> URL: https://issues.apache.org/jira/browse/ARTEMIS-184
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: Howard Gao
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-176) GC Durable Subscriptions

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-176:
--
Fix Version/s: (was: 2.0.0)
   2.next

> GC Durable Subscriptions
> 
>
> Key: ARTEMIS-176
> URL: https://issues.apache.org/jira/browse/ARTEMIS-176
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: clebert suconic
> Fix For: 2.next
>
>
> There should be a way to GC durable subscriptions when not used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-29) Reconnect to any live

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-29:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Reconnect to any live
> -
>
> Key: ARTEMIS-29
> URL: https://issues.apache.org/jira/browse/ARTEMIS-29
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
>Priority: Critical
> Fix For: 2.next
>
>
> Right now clients will always connect to their backup or original lives.
> We could in a configurable fashion have the client connecting anywhere after 
> a certain number of retries to their original nodes. 
> (This will only be applied to core clients since AMQP will always reconnect 
> to their original addresses).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-60) Transactionally consumed AMQP messages are settled without any disposition state.

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-60:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Transactionally consumed AMQP messages are settled without any disposition 
> state.
> -
>
> Key: ARTEMIS-60
> URL: https://issues.apache.org/jira/browse/ARTEMIS-60
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 2.next
>
>
> When the broker receives an unsettled disposition frame from a consumer 
> accepting a message using TransactionalState to make it part of a 
> transaction, it settles the message but does so with no state at all. This 
> process causes a settled disposition frame to be sent to the client which 
> contains no state. The message should retain TransactionalState linking it to 
> the transaction and its outcome.
> Similar issue to AMQ-5456 for ActiveMQ 5.
> The issue can be seen in the protocol trace below:
> {noformat}
> 
>   
>   
>   
>
> 
>  # disposition
>  # disposition
># role
># first
># last
># settled
># state   TransactionalState
># state
>  # txn-id
>   00 00 00 00 00 00 00 0d 
> 
>  # outcome
>  # accepted
>   
>   #  batchable [false]
> 
> 
>   
>   
> 
> {noformat}
> {noformat}
> 
>   
>   
>   
>
> 
>  # disposition
>  # disposition
># role
>1  # first
>1  # last
># settled
>   #  state No state
>   #  batchable [false]
> 
> 
>   
>   
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-566) Cannot remove JMS queue that has been removed from Core side

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-566:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Cannot remove JMS queue that has been removed from Core side
> 
>
> Key: ARTEMIS-566
> URL: https://issues.apache.org/jira/browse/ARTEMIS-566
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.2.0, 1.3.0
>Reporter: Ville Skyttä
>Priority: Minor
> Fix For: 2.next
>
>
> If a queue that has been created from the JMS side is removed from the Core 
> side in JMX, a phantom JMS queue is left behind which cannot be removed.
> 1) Start jconsole, connect to artemis
> 2) Navigate in mbeans to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> 
> JMS -> Server -> Operations
> 3) Invoke createQueue TestQueue
> 4) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core, note 
> that jms.queue.TestQueue is in both Address and Queue
> 5) Navigate to org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core -> 
> Server -> Operations
> 6) Invoke destroyQueue TestQueue
> 7) Note that jms.queue.TestQueue disappears from Address and Queue from 
> org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> Core (as expected)
> 8) Navigate to Navigate in mbeans to org.apache.activemq.artemis -> Broker -> 
> 0.0.0.0 -> JMS -> Queue
> 9) Note that TestQueue is still listed
> 10) Try to remove it with destroyQueue TestQueue from 
> org.apache.activemq.artemis -> Broker -> 0.0.0.0 -> JMS -> Server -> 
> Operations
> 11) Get ActiveMQNonExistentQueueException, and the queue is not removed
> A workaround is to restart artemis, that results in the Core side queue 
> becoming visible again, and then step 10) succeeds.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-192) Implement Exclusive Consumer feature

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-192:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Implement Exclusive Consumer feature
> 
>
> Key: ARTEMIS-192
> URL: https://issues.apache.org/jira/browse/ARTEMIS-192
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
> Fix For: 2.next
>
>
> The concept is pretty much similar to "message group", which pins messages on 
> a queue to one consumer, in order to get message order.
> ref: http://activemq.apache.org/exclusive-consumer.html
> Test: JMSExclusiveConsumerTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-161) Graceful shutdown: add a timeout to stop Artemis

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-161:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Graceful shutdown: add a timeout to stop Artemis
> 
>
> Key: ARTEMIS-161
> URL: https://issues.apache.org/jira/browse/ARTEMIS-161
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 2.next
>
>
> We want to provide a graceful shutdown for Artemis to leave some time for JMS 
> clients to finish their work before stopping the server.
> This is also covered by ARTEMIS-72 which deals with refusing new remote 
> connections once the shutdown process is started (while keeping in-vm 
> connections opened).
> This issue is about specifying a timeout when stopping the ActiveMQServer.
> It is possible to provide a general shutdown timeout in the server 
> configuration but this is not suitable.
> A shutdown process is contextual: it may be a quick shutdown in case of 
> emergency (with a timeout of some seconds) or a long timeout (several hours) 
> in case of planned upgrade for example.
> This parameter should be specified when the admin starts the shutdown process 
> and be passed to the ActiveMQServer (and its wrapping JMSServerManger) stop() 
> method.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-160) After failback backup prints warnings to log

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-160:
--
Fix Version/s: (was: 2.0.0)
   2.next

> After failback backup prints warnings to log
> 
>
> Key: ARTEMIS-160
> URL: https://issues.apache.org/jira/browse/ARTEMIS-160
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.0.0
>Reporter: Jeff Mesnil
>Assignee: Justin Bertram
> Fix For: 2.next
>
>
> We integrate Artemis in our app server.
> When the artemis server is stopped, we want to unregister any JNDI bindings 
> for the JMS resources.
> For failback, the only way to detect that the artemis server is stopped is to 
> use the ActivateCallback callback on Artemis *core* server. There is no way 
> to be notified when the JMS server (wrapping the core server) is stopped.
> This leads to a window where we remove JNDI bindings from the JMS server 
> before it is deactivated but the actual operations is performed after it was 
> deactivated and the server prints WARNING logs:
> {noformat}
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService 
> Thread Pool – 4) WFLYMSGAMQ0004: Failed to destroy queue: ExpiryQueue: 
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not 
> yet active
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService 
> Thread Pool – 68) WFLYMSGAMQ0004: Failed to destroy queue: AsyncQueue: 
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not 
> yet active
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 15:34:59,123 WARN [org.wildfly.extension.messaging-activemq] (ServerService 
> Thread Pool – 9) WFLYMSGAMQ0004: Failed to destroy queue: DLQ: 
> java.lang.IllegalStateException: Cannot access JMS Server, core server is not 
> yet active
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.checkInitialised(JMSServerManagerImpl.java:1640)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.access$1100(JMSServerManagerImpl.java:101)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl$3.runException(JMSServerManagerImpl.java:752)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.runAfterActive(JMSServerManagerImpl.java:1847)
> at 
> org.apache.activemq.artemis.jms.server.impl.JMSServerManagerImpl.removeQueueFromBindingRegistry(JMSServerManagerImpl.java:741)
> at 
> org.wildfly.extension.messaging.activemq.jms.JMSQueueService$2.run(JMSQueueService.java:101)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}

[jira] [Updated] (ARTEMIS-189) Support Queue wildcard usecase

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-189:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Support Queue wildcard usecase
> --
>
> Key: ARTEMIS-189
> URL: https://issues.apache.org/jira/browse/ARTEMIS-189
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Minor
> Fix For: 2.next
>
>
> Client should be able to create a Queue with wild card
> Foo.>
> Then create a consumer to it.
> Then create a queue like FOO.BAR.HUMBUG
> sends a few messages to it.
> The consumer should be able to receive it.
> Ref: JmsDurableQueueWildcardSendReceiveTest, JmsQueueWildcardSendReceiveTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-729) Review JDBC Storage

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-729:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Review JDBC Storage
> ---
>
> Key: ARTEMIS-729
> URL: https://issues.apache.org/jira/browse/ARTEMIS-729
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: clebert suconic
>Assignee: clebert suconic
>Priority: Critical
> Fix For: 2.next
>
>
> two issues that I see:
> - When an SQL Exception happens a couple of the data-structures are put back, 
> this is wrong: it should rollback and retry a couple times, if the exception 
> persists it's a critical error and the system should be shutdown. (just like 
> it would with an IO Exception through the file journal).
> - There is too much contention on sync. The idea of sync is to release 
> contention however the datas are overly synchronized making it impossible to 
> add more records while the system is performing any DB operations. Which 
> defies the purpose.
> I'm setting this as a blocker just to make sure we would review before 
> releasing 1.5.0.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-24) Lazy conversions on Protocols / Persistency

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-24:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Lazy conversions on Protocols / Persistency
> ---
>
> Key: ARTEMIS-24
> URL: https://issues.apache.org/jira/browse/ARTEMIS-24
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
> Fix For: 2.next
>
>
> We should do like apollo on converting between Protocols and persisting data. 
> We should keep the data native as much as we can to the protocol and only 
> convert when needed.
> Right now we are always converting to an internal format independently of the 
> protocol.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-196) Implementing Consumer Priority

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-196:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Implementing Consumer Priority
> --
>
> Key: ARTEMIS-196
> URL: https://issues.apache.org/jira/browse/ARTEMIS-196
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
> Fix For: 2.next
>
>
> ref: http://activemq.apache.org/consumer-priority.html
> org.apache.activemq.QueueConsumerPriorityTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-85) Add support for HA cluster / failover discovery using DNS SRV records

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-85:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Add support for HA cluster / failover discovery using DNS SRV records
> -
>
> Key: ARTEMIS-85
> URL: https://issues.apache.org/jira/browse/ARTEMIS-85
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Daniel Pocock
> Fix For: 2.next
>
>
> Copied from HORNETQ-1270
> The DNS SRV record provides a convenient and well known mechanism to 
> configure active-active, load balanced clusters and to provide failover 
> information.
> It is convenient for many people because they already have DNS servers and 
> support staff are usually familiar with the procedures for maintaining the 
> DNS entries.
> DNS SRV also allows port numbers to be advertised.
> The clustering support using UDP multicast doesn't work for all sites, 
> especially where the user is more concerned with failover than load-balancing.
> A specific DNS SRV implementation may involve some or all of the following:
> - clients discovering a HornetQ, JNDI or STOMP host and port
> - servers dynamically deciding which IPs and ports to bind to by checking DNS 
> SRV records
> - servers dynamically deciding which other servers to cluster with by 
> checking for DNS SRV records
> DNS SRV records may look like this:
> _stomp._tcp.test-mq.example.org. IN SRV 1 50 5566 testmqhost1.example.org.
> _stomp._tcp.test-mq.example.org. IN SRV 2 50 5566 testmqbackup.example.org.
> A STOMP client would then be configured with just the domain name 
> "test-mq.example.org" and it would dynamically discover the hosts and ports 
> from DNS



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-173) Document migration path for all activemq5 features

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-173:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Document migration path for all activemq5 features
> --
>
> Key: ARTEMIS-173
> URL: https://issues.apache.org/jira/browse/ARTEMIS-173
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: clebert suconic
>Priority: Critical
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-198) Streamlet message support

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-198:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Streamlet message support
> -
>
> Key: ARTEMIS-198
> URL: https://issues.apache.org/jira/browse/ARTEMIS-198
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
>Priority: Minor
> Fix For: 2.next
>
>
> Client can create an inputStream and outputStream directly on connections to 
> write and receive data from a destination. 
> Minor because the API marked as deprecated.
> See test:
> LargeStreamletTest



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-75) Recovery Manager should raise/log error when multiple ActiveMQRegistry service providers are registered.

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-75:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Recovery Manager should raise/log error when multiple ActiveMQRegistry 
> service providers are registered.
> 
>
> Key: ARTEMIS-75
> URL: https://issues.apache.org/jira/browse/ARTEMIS-75
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
> Fix For: 2.next
>
>
> Since we are now using the Service Loader to load instances of the 
> ActiveMQRegistry, it is now possible that more than one Service Provider for 
> the registry can be loaded.  We should log an error if more than 1 service 
> provider is found.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-717) Use hash buckets for JMSXGroupID to reduce system impact when there are lots of groups

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-717:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Use hash buckets for JMSXGroupID to reduce system impact when there are lots 
> of groups
> --
>
> Key: ARTEMIS-717
> URL: https://issues.apache.org/jira/browse/ARTEMIS-717
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.4.0
>Reporter: Michael Brown
> Fix For: 2.next
>
>
> Currently Artemis maintains an association of JMSXGroupID to consumer on a 
> one to one level, puting high burden on the broker.
> The sibiling project ArtemisMQ has solved this with the use of hash buckets. 
> I suggest that Artemis does the same.
> https://issues.apache.org/jira/browse/AMQ-439



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-235) Map content-type to message type on Stomp

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-235:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Map content-type to message type on Stomp
> -
>
> Key: ARTEMIS-235
> URL: https://issues.apache.org/jira/browse/ARTEMIS-235
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0
>Reporter: clebert suconic
>Assignee: Justin Bertram
> Fix For: 2.next
>
>
> As documented at 
> https://activemq.apache.org/artemis/docs/1.0.0/interoperability.html#sending-and-consuming-stomp-message-from-jms-or-apache-activemq-artemis-core-api
> Will convert bytes message or text message when the size is available. 
> it would been better to use content-type.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-59) AMQP messages published transactionally should be accepted using a TransactionalState

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-59:
-
Fix Version/s: (was: 2.0.0)
   2.next

> AMQP messages published transactionally should be accepted using a 
> TransactionalState
> -
>
> Key: ARTEMIS-59
> URL: https://issues.apache.org/jira/browse/ARTEMIS-59
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 2.next
>
>
> Currently, when an incoming AMQP message is part of a transaction, it is 
> accepted using the regular Accepted terminal state on the disposition reply. 
> According to the spec [1] the disposition should actually use a 
> TransactionalState with Accepted outcome.
> Similar issue to AMQ-5352 for ActiveMQ 5.
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp111808
> The issue can be seen in the following protocol traces.
> The transactional message transfer from the producer:
> {noformat}
> 
>   
>   
>   
>
> 
>  # transfer
>  # transfer
>1  # handle
>1  # delivery-id
># delivery-tag
> "0"
>   
># message-format
># settled
># more
># rcv-settle-mode
># state  
> Transactional state
># state
>  # txn-id
>   00 00 00 00 7f ff ff ff 
> 
> #  outcome
>   
>   #  resume [false]
>   #  aborted [false]
>   #  batchable [false]
> 
> 
>  # header
>  # header
># durable
>   #  priority
>   #  ttl
>   #  first-acquirer
>   #  delivery-count
> 
> 
>  # message-annotations
>  # message-annotations
>   
> "x-opt-jms-msg-type"
>   
>5 
>   
> "x-opt-to-type"
>   
>0 
> 
> 
>  # properties
>  # properties
># message-id
> "localhost.localdomai"
> "n-48953-141840504087"
> "8-0:1:1:1-1"
>   
># user-id
># to
> "myQueue"
>   
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
>   #2014/12/12 17:24:01.614 # creation-time
>   #  group-id
>   #  group-sequence
>   #  reply-to-group-id
> 
> 
>  # amqp-value
>  # amqp-value
>   "Hello world!"
> 
> 
>   
>   
> 
> {noformat}
> The disposition for this message can then be seen being updated by the broker 
> the Accepted state, rather than a TransactionalState identifying the 
> transaction and containing the Accepted outcome:
> {noformat}
> 
>   
>   
>   
>
> 
>  # disposition
>  # disposition
># role
>1  # first
>1  # last
># settled
># state    
> Non-Transactional state
># accepted
>   #  batchable [false]
> 
> 
>   
>   
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-540) Supporting openshift as source of service discovery

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-540:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Supporting openshift as source of service discovery
> ---
>
> Key: ARTEMIS-540
> URL: https://issues.apache.org/jira/browse/ARTEMIS-540
> Project: ActiveMQ Artemis
>  Issue Type: Wish
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Kaiming Yang
> Fix For: 2.next
>
>
> Artemis Apache MQ currently only support broadcast for service discovery. 
> At our company that is not allowed, hence we are looking to provide a plugin 
> that can use a different service discovery mechanism.
> At our company we are using OpenShift 3.x, which provides service 
> discovery/lookup itself. We are looking to provide a mechanism that leverages 
> OSE as the service to provide Artemis cluster information dynamically and are 
> looking to provide those contributions back to the community.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-33) Generic integration with SASL Frameworks

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-33:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Generic integration with SASL Frameworks
> 
>
> Key: ARTEMIS-33
> URL: https://issues.apache.org/jira/browse/ARTEMIS-33
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: clebert suconic
>Priority: Critical
> Fix For: 2.next
>
>
> Right now we are bound to User/Password or anonymous on SASL.
> We should use some framework that would allow SASL integration with a bigger 
> number of possibilities.
> We should investigate options from the JDK for this... or if there is any 
> other framework available.
> I believe this only affects AMQP, but as part of this issue we should 
> investigate if there is any interest extending SASL into any other protocol.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-821) Support scheduled messages with the STOMP protocol

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-821:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Support scheduled messages with the STOMP protocol
> --
>
> Key: ARTEMIS-821
> URL: https://issues.apache.org/jira/browse/ARTEMIS-821
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.4.0
>Reporter: Jiri Danek
>Priority: Blocker
> Fix For: 2.next
>
>
> Scheduled messages are already supported with Core and with AMQP. Scheduled 
> messages are JMS 2.0 feature.
> I would like to request their support in STOMP protocol. This feature has 
> been also requested in [a Stack Overflow 
> question|http://stackoverflow.com/q/38996576/6081394].



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-864) Sending to a destroyed temp queue didn't get exception

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-864:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Sending to a destroyed temp queue didn't get exception
> --
>
> Key: ARTEMIS-864
> URL: https://issues.apache.org/jira/browse/ARTEMIS-864
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: OpenWire
>Affects Versions: 1.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Minor
> Fix For: 2.next
>
>
> When client sends a non persistent message to an already destroyed temp 
> queue, client should get a InvalidDestinationException. However the sending 
> returns normally even though the broker side logs such an exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-70) Implement resource limits

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-70:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Implement resource limits
> -
>
> Key: ARTEMIS-70
> URL: https://issues.apache.org/jira/browse/ARTEMIS-70
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Michael Cressman
>Assignee: Justin Bertram
>Priority: Critical
> Fix For: 2.next
>
>
> Implement various resource limits within the system:
> - overall number of connections
> - connections per user
> - connections per IP address
> - queues per user
> - (possibly: number of sessions, number of subscriptions per user)
> The "per user" limits can be a default maximum for everyone plus specific 
> limits for particular users.
> Other things:
> - limit the max queue size a user can create
> - limit the names a user may call a queue that he creates



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-183) Fix openwire tests under org.apache.activemq.openwire package

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-183:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix openwire tests under org.apache.activemq.openwire package
> -
>
> Key: ARTEMIS-183
> URL: https://issues.apache.org/jira/browse/ARTEMIS-183
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: Howard Gao
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-829) Core Protocol Producers will re-encode messages on the server

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-829:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Core Protocol Producers will re-encode messages on the server
> -
>
> Key: ARTEMIS-829
> URL: https://issues.apache.org/jira/browse/ARTEMIS-829
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0
>Reporter: clebert suconic
>Assignee: clebert suconic
> Fix For: 2.next
>
>
> In an attempt to optimize small message producers, the producer will remove 
> the address from the message and re-encode it on the server. that will make 
> Netty to double the size, and remove the former buffer, what will generate 
> more memory throughput for the same mesage.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-169) Fix imported open wire tests

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-169:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix imported open wire tests
> 
>
> Key: ARTEMIS-169
> URL: https://issues.apache.org/jira/browse/ARTEMIS-169
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: clebert suconic
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-66) implement configuration persistence

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-66:
-
Fix Version/s: (was: 2.0.0)
   2.next

> implement configuration persistence
> ---
>
> Key: ARTEMIS-66
> URL: https://issues.apache.org/jira/browse/ARTEMIS-66
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Andy Taylor
> Fix For: 2.next
>
>
> We should reflect changes thru management such as adding destinations in the 
> configuration file.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-185) 100% transparent failover

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-185:
--
Fix Version/s: (was: 2.0.0)
   2.next

> 100% transparent failover
> -
>
> Key: ARTEMIS-185
> URL: https://issues.apache.org/jira/browse/ARTEMIS-185
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: Miroslav Novak
> Fix For: 2.next
>
>
> The client should cache any transactional data, and verify if the information 
> had reached the server or not upon reconnection (through either failover or 
> reconnection).
> Currently standalone JMS client throws exception (ArtemisException or 
> JMSException) to client application code during failover/failback and leaves 
> on application programmer to handle this exception and retry the last 
> operation.
> This makes client code complex and developer must spent additional effort to 
> handle those edge cases. This is complicated to achieve especially for 
> consumer with transacted session of client acknowledge.
> Goal of this RFE is to provide exception free behaviour for standalone JMS 
> clients.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-898) Artemis Plugin Support

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-898:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Artemis Plugin Support
> --
>
> Key: ARTEMIS-898
> URL: https://issues.apache.org/jira/browse/ARTEMIS-898
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Reporter: Matt Pavlovich
> Fix For: 2.next
>
>
> ActiveMQ 5.x currently has a number of extension points via Plugins, or 
> simple Spring bean wiring. Artemis should provide extension points to meet 
> various requirements.
> The protocol interceptors are handy, but also limiting in that each plugin 
> would need to be implemented for every protocol. Feels like there should be 
> defined extension point(s) within the broker.
> Core Broker Plugins:
> 1. Message header / property manipulation
> 2. Message body manipulation
> 3. Activity tracing (broker becomes master, network bridge start/stop, 
> message rcv/sent/ack/rollback, consumer/producer add/remove, broker 
> add/remove, destination add/remove, connection add/remove, fast producer/slow 
> consumer, etc)
>  a. Audit / trace logs
>  b. Triggers based on events
> ref: 
> http://activemq.apache.org/maven/apidocs/org/apache/activemq/broker/MutableBrokerFilter.html
> Additional extension point:
>  DestinationPolicies: Ability to impact destination behaviors for dispatch, 
> subscription policies, etc.
> Side benefit regarding Advisory Support:
> If the plugin framework can get squared away, an upside could be that 
> Advisory support becomes a plugin vs an ingrained feature and we could have 
> more control over configuration and behavior.
> From ARTEMIS-17
> Support for using Camel as an interceptor/plugin



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-81) Verify the activemq-rest is working and review messaging model

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-81:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Verify the activemq-rest is working and review messaging model
> --
>
> Key: ARTEMIS-81
> URL: https://issues.apache.org/jira/browse/ARTEMIS-81
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Reporter: Martyn Taylor
>Assignee: Martyn Taylor
>Priority: Critical
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-600) Enterprise message grouping

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-600:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Enterprise message grouping
> ---
>
> Key: ARTEMIS-600
> URL: https://issues.apache.org/jira/browse/ARTEMIS-600
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Miroslav Novak
>Priority: Critical
> Fix For: 2.next
>
>
> Message grouping in Artemis is squishy as almost anything can break it at 
> this moment. *Drawbacks in current design:*
> * Consumers must be connected before messages are send to cluster
> * If producers sends message to cluster and there is no consumer in cluster 
> then message is stuck on this node. Consumer which later connects to another 
> node in cluster does not receive this message.
> * If server in cluster is shutdown then all message grouping breaks and no 
> other node in cluster is able to receive message (not even on other queues)
> * There is issue that backup for remote grouping handler does not take duties 
> after failover.
> * If consumer is closed then no other consumer is chosen
> *Suggested improvements:*
> * Decision to which consumer to route a message, will not be made during send 
> time in case that there is no consumer. 
> * Consumers do not have to be connected when messages are sent to cluster.
> * Message grouping will allow to cleanly shutdown server without breaking 
> message ordering/grouping. Connected consumers will be closed. Another 
> consumer in cluster will be chosen.
> * Futher If any consumer is closed then another consumer will be chosen. 
> * Allow to configure dispatch delay to avoid situation that first connected 
> consumer in cluster gets assigned all message groups. Delay will wait for 
> other consumers to connect so message groups are equally distributed. (we can 
> consider setting minimum consumer number)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-31) Disaster recovery

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-31:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Disaster recovery
> -
>
> Key: ARTEMIS-31
> URL: https://issues.apache.org/jira/browse/ARTEMIS-31
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
> Fix For: 2.next
>
>
> allow some sort of disaster recovery



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-57) the 'to' field of AMQP messages gets cleared within the broker

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-57:
-
Fix Version/s: (was: 2.0.0)
   2.next

> the 'to' field of AMQP messages gets cleared within the broker
> --
>
> Key: ARTEMIS-57
> URL: https://issues.apache.org/jira/browse/ARTEMIS-57
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 2.next
>
>
> When sending and receiving AMQP messages, the 'to' field of the Properties 
> section (which is meant to be immutable) is cleared as the message transits 
> through the broker.
> The encoding on the wire of a message Properties section as it was sent to 
> the broker:
> {noformat}
>  # properties
>  # properties
># message-id
> "localhost.localdomai"
> "n-54104-141838672362"
> "2-0:1:1:1-1"
>   
># user-id
># to
> "myQueue"
>   
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
>   #2014/12/12 12:18:44.423 # creation-time
>   #  group-id
>   #  group-sequence
>   #  reply-to-group-id
> 
> {noformat}
> The encoding on the wire on its way to a consumer:
> {noformat}
>  # properties
>  # properties
># message-id
># user-id
># to
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
>   #2014/12/12 12:18:44.423 # creation-time
>   #  group-id
>   #  group-sequence
>   #  reply-to-group-id
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-181) Fix openwire tests under org.apache.activemq package

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-181:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix openwire tests under org.apache.activemq package
> 
>
> Key: ARTEMIS-181
> URL: https://issues.apache.org/jira/browse/ARTEMIS-181
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: Howard Gao
>Assignee: Howard Gao
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-775) AMQP: Message seems to be delivered twice when receiver close with pending messages

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-775:
--
Fix Version/s: (was: 2.0.0)
   2.next

> AMQP: Message seems to be delivered twice when receiver close with pending 
> messages
> ---
>
> Key: ARTEMIS-775
> URL: https://issues.apache.org/jira/browse/ARTEMIS-775
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.4.0
>Reporter: Timothy Bish
>Assignee: Martyn Taylor
>Priority: Blocker
> Fix For: 2.next
>
>
> Scenario:
> 1. Send 10 messages to the broker
> 2. Open a receiver and grant credit (10)
> 3. Read one message but don't accept
> 4. Close the receiver
> 5. Open new receiver and grant credit (11 or more)
> 6. Try to read those 10 message you send, and you get 11 one being a 
> duplicate.
> PR with a test case to follow



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-30) allow backup servers to service multiple live servers

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-30:
-
Fix Version/s: (was: 2.0.0)
   2.next

> allow backup servers to service multiple live servers
> -
>
> Key: ARTEMIS-30
> URL: https://issues.apache.org/jira/browse/ARTEMIS-30
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
> Fix For: 2.next
>
>
> On this you could have a number of backup Nodes (M) serving a number of live 
> Nodes (N)
> On that scenario you would always have N+M nodes. you would only support M 
> lives failing on this scenario.
> Right now a backup can only support one live. With this we would allow it to 
> serve multiple lives.
> I'm not sure yet if this applies to replication as well. It's easy to be 
> implemented with shared storage. We will need to investigate if this makes 
> sense with replication or not. (To be discussed during design discussions 
> before the implementation)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-203) Investigate removal of namespaces for queues / topics

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-203:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Investigate removal of namespaces for queues / topics
> -
>
> Key: ARTEMIS-203
> URL: https://issues.apache.org/jira/browse/ARTEMIS-203
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: Martyn Taylor
> Fix For: 2.next
>
>
> We are currently using address name spacing on the broker to determine the
> message producer client type, for example producing from a jms client results 
> in messages being posted to jms.queue.*** where *** is the address provided 
> by the client.  The has caused some confusions for users who were expecting 
> to produce and consume to the same address using different clients.  
> This also has a couple of other consequences:
> 1. Messages can not be produced to the same queue by AMQP and JMS.
> 2. Consumers need to be aware of the producer client type so they can 
> subscribe to the appropriately namespaced address.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-28) Rebalance load

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-28:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Rebalance load
> --
>
> Key: ARTEMIS-28
> URL: https://issues.apache.org/jira/browse/ARTEMIS-28
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: clebert suconic
>Assignee: Andy Taylor
>Priority: Critical
> Fix For: 2.next
>
>
> Rebalance load after a node has too much load after certain events.
> It could be after failover, or after scaling up (starting new nodes on the 
> cluster)
> It's not certain if this is just about connections or also about data (queues 
> and topics). We believe that if we just did this on connection level, 
> ACTIVEMQ6-25 would take care of redistributing the data.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-355) Duplex bridges

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-355:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Duplex bridges
> --
>
> Key: ARTEMIS-355
> URL: https://issues.apache.org/jira/browse/ARTEMIS-355
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>  Components: Broker
>Affects Versions: 1.2.0
>Reporter: Mike Hearn
>Assignee: Martyn Taylor
> Fix For: 2.next
>
>
> I can't find any way to make an embedded artemis A connect to an embedded 
> artemis B such that B can send messages to A without connectivity at the TCP 
> level, e.g. due to firewall traversal. It'd be convenient if there was no 
> need for me to implement firewall punching myself. Apparently ActiveMQ can do 
> this using some sort of "duplex" attribute, but it's not in Artemis.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-190) Message Eviction and its Tests

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-190:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Message Eviction and its Tests
> --
>
> Key: ARTEMIS-190
> URL: https://issues.apache.org/jira/browse/ARTEMIS-190
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Affects Versions: 1.0.0
>Reporter: Howard Gao
> Fix For: 2.next
>
>
> Message Eviction means to keep a limited number of messages in broker memory 
> for consumers to a non-durable topic and drop the old messages as new 
> messages come in, in order to keep the limit.
> ref: http://activemq.apache.org/slow-consumer-handling.html
> The MessageEvictionTest needs to be refactored as it does the testing by 
> examining the internal status of activemq broker objects, which is not 
> applicable to the new artemis broker.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-72) Increment graceful shutdown scenarios and add more tests

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-72:
-
Fix Version/s: (was: 2.0.0)
   2.next

> Increment graceful shutdown scenarios and add more tests
> 
>
> Key: ARTEMIS-72
> URL: https://issues.apache.org/jira/browse/ARTEMIS-72
> Project: ActiveMQ Artemis
>  Issue Type: Task
>Affects Versions: 1.0.0
>Reporter: Justin Bertram
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-182) Fix openwire tests under org.apache.activemq.command package

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-182:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Fix openwire tests under org.apache.activemq.command package
> 
>
> Key: ARTEMIS-182
> URL: https://issues.apache.org/jira/browse/ARTEMIS-182
> Project: ActiveMQ Artemis
>  Issue Type: Sub-task
>  Components: OpenWire
>Reporter: Howard Gao
> Fix For: 2.next
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-155) Incoming AMQP connection using "cut-through" ANONYMOUS SASL fails

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-155:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Incoming AMQP connection using "cut-through" ANONYMOUS SASL fails
> -
>
> Key: ARTEMIS-155
> URL: https://issues.apache.org/jira/browse/ARTEMIS-155
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Ted Ross
>Assignee: Andy Taylor
>Priority: Minor
> Fix For: 2.next
>
>
> When connecting an AMQP 1.0 connection to the broker using SASL ANONYMOUS, 
> the following exchange occurs:
> {noformat}
>   ClientBroker
> init(SASL) ->
> sasl.init (ANON) ->
> init(AMQP) ->
> open ->
>  <- init(SASL)
>  <- sasl.mechanisms
>  <- sasl.outcome(OK)
>  <- init(AMQP)
>  socket closed by broker after timeout
> {noformat}
> It appears the the broker doesn't process the open frame.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-245) Change resource adapter to work with Tomee

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-245:
--
Fix Version/s: (was: 2.0.0)
   2.next

> Change resource adapter to work with Tomee
> --
>
> Key: ARTEMIS-245
> URL: https://issues.apache.org/jira/browse/ARTEMIS-245
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 1.1.0, 1.2.0
>Reporter: clebert suconic
> Fix For: 2.next
>
> Attachments: patch.txt
>
>
> It seems that Tomee requires a JMS interface to be returned. We should try 
> changing the RA to be compatible with it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-908) AMQP flow control misses unblock during heavy load

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-908:
--
Fix Version/s: (was: 2.0.0)
   2.next

> AMQP flow control misses unblock during heavy load
> --
>
> Key: ARTEMIS-908
> URL: https://issues.apache.org/jira/browse/ARTEMIS-908
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Reporter: Ulf Lilleengen
>Assignee: Justin Bertram
> Fix For: 2.next
>
>
> I have a benchmarking setup with 1 sender and 1 receiver attached to a 
> broker. The broker is configured with BLOCK policy when queue is full, and 
> I've deliberately set a low global-max-size to trigger this bug.
> While sending messages, I get tons of these in the Artemis log, due to the 
> flow control kicking in:
> 10:46:53,673 WARN  [org.apache.activemq.artemis.core.server] AMQ222183: 
> Blocking message production on address 'myqueue'; size is currently: 105,456 
> bytes; max-size-bytes: -1
> 10:46:53,674 INFO  [org.apache.activemq.artemis.core.server] AMQ221046: 
> Unblocking message production on address 'myqueue'; size is currently: 
> 105,456 bytes; max-size-bytes: -1
> However, usually after running the test for 10-30 seconds, the sender is 
> suddenly never unblocked and I have to restart the sender to send more 
> messages. Every time I attach the sender, I am able to send messages for 
> 10~30 seconds until it stops. 
> This happens with different clients, and triggers only if it can send 
> messages really fast.
> After inspecting the flow control logic in the AMQP implementation, I noticed 
> that there is a missing synchronized block when issuing credits in 
> AMQPSessionCallback#offerProducerCredit, which is present in 
> ProtonServerReceiverContext#flow (if sessionSPI is null).
> Adding a synchronized block with the connection lock to the function passed 
> to store.checkMemory() in AMQPSessionCallback#offerProducerCredit (in the 
> same way as in ProtonServerReceiverContext#flow), the sender seems to be 
> unblocked correctly. I've been able to run the sender and receiver for 5 
> minutes without issues so far. 
> I'll submit the patch as a github PR.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-56) the message-id of AMQP messages gets cleared within the broker

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-56:
-
Fix Version/s: (was: 2.0.0)
   2.next

> the message-id of AMQP messages gets cleared within the broker
> --
>
> Key: ARTEMIS-56
> URL: https://issues.apache.org/jira/browse/ARTEMIS-56
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP
>Affects Versions: 1.0.0
>Reporter: Robbie Gemmell
> Fix For: 2.next
>
>
> When sending and receiving AMQP messages, the message-id field of the 
> Properties section (which is meant to be immutable) is cleared as the message 
> transits through the broker.
> The encoding on the wire of a message Properties section as it was sent to 
> the broker:
> {noformat}
>  # properties
>  # properties
># message-id
> "localhost.localdomai"
> "n-54104-141838672362"
> "2-0:1:1:1-1"
>   
># user-id
># to
> "myQueue"
>   
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
>   #2014/12/12 12:18:44.423 # creation-time
>   #  group-id
>   #  group-sequence
>   #  reply-to-group-id
> 
> {noformat}
> The encoding on the wire on its way to a consumer:
> {noformat}
>  # properties
>  # properties
># message-id
># user-id
># to
># subject
># reply-to
># correlation-id
># content-type
># content-encoding
># absolute-expiry-time
>   #2014/12/12 12:18:44.423 # creation-time
>   #  group-id
>   #  group-sequence
>   #  reply-to-group-id
> 
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (ARTEMIS-1024) Management operation causes ClassNotFoundException

[Martyn Taylor (JIRA)]

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

Martyn Taylor updated ARTEMIS-1024:
---
Fix Version/s: (was: 2.0.0)
   2.next

> Management operation causes ClassNotFoundException
> --
>
> Key: ARTEMIS-1024
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1024
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.5.3
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Minor
> Fix For: 2.next
>
>
> Artemis expose createQueue() method to management console like Jon. If the 
> queue to be created already exists it throws an ActiveMQException back to the 
> console, which will get a ClassNotFoundException when deserializing the 
> exception. 
> To fix that it should throw a common java exception like 
> IllegalStateException.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-894) Add a PooledConnectionFactory to artemis-jms-client

[Martyn Taylor (JIRA)]

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

Martyn Taylor closed ARTEMIS-894.
-

> Add a PooledConnectionFactory to artemis-jms-client
> ---
>
> Key: ARTEMIS-894
> URL: https://issues.apache.org/jira/browse/ARTEMIS-894
> Project: ActiveMQ Artemis
>  Issue Type: New Feature
>Reporter: Matt Pavlovich
>
> Add a PooledConnectionFactory (or support for pooling in 
> ActiveMQConnectionFactory class) to the artemis-jms-client. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (ARTEMIS-553) Example examples/features/sub-modules/vertx is failing

[Martyn Taylor (JIRA)]

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

Martyn Taylor closed ARTEMIS-553.
-

> Example examples/features/sub-modules/vertx is failing
> --
>
> Key: ARTEMIS-553
> URL: https://issues.apache.org/jira/browse/ARTEMIS-553
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 1.3.0
>Reporter: Jiri Danek
>  Labels: examples
> Attachments: netstat.log, vertx.log
>
>
> Steps to reproduce:
> {{cd examples/features/sub-modules/vertx}}
> {{mvn verify}}
> The above prints the following
> ...
> {noformat}
> Jun 07, 2016 10:52:23 AM com.hazelcast.instance.Node
> WARNING: [169.254.239.74]:5702 [dev] [3.2.3] Config seed port is 5701 and 
> cluster size is 1. Some of the ports seem occupied!
> Jun 07, 2016 10:52:23 AM com.hazelcast.core.LifecycleService
> INFO: [169.254.239.74]:5702 [dev] [3.2.3] Address[169.254.239.74]:5702 is 
> STARTED
> Jun 07, 2016 10:52:24 AM com.hazelcast.partition.InternalPartitionService
> INFO: [169.254.239.74]:5702 [dev] [3.2.3] Initializing cluster partition 
> table first arrangement...
> server0-out:10:52:33,319 INFO  [com.hazelcast.cluster.MulticastJoiner] 
> [169.254.239.74]:5703 [dev] [3.2.3] 
> {noformat}
> ...
> {noformat}
> server0-out:10:52:33,320 INFO  [com.hazelcast.core.LifecycleService] 
> [169.254.239.74]:5703 [dev] [3.2.3] Address[169.254.239.74]:5703 is STARTED
> Jun 07, 2016 10:52:39 AM org.vertx.java.core.logging.impl.JULLogDelegate error
> SEVERE: Exception in Java verticle
> java.util.concurrent.RejectedExecutionException: Task 
> org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1@2867fcb1 
> rejected from java.util.concurrent.ThreadPoolExecutor@42731816[Shutting down, 
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 4]
> at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at 
> org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor.execute(OrderedExecutorFactory.java:111)
> at 
> org.vertx.java.core.impl.DefaultContext.executeOnOrderedWorkerExec(DefaultContext.java:156)
> at 
> org.vertx.java.core.impl.DefaultVertx.executeBlocking(DefaultVertx.java:402)
> at 
> org.vertx.java.spi.cluster.impl.hazelcast.HazelcastAsyncMultiMap.remove(HazelcastAsyncMultiMap.java:136)
> at 
> org.vertx.java.core.eventbus.impl.DefaultEventBus.removeSub(DefaultEventBus.java:896)
> at 
> org.vertx.java.core.eventbus.impl.DefaultEventBus.unregisterHandler(DefaultEventBus.java:484)
> at 
> org.vertx.java.core.eventbus.impl.DefaultEventBus.unregisterHandler(DefaultEventBus.java:502)
> at 
> org.vertx.java.core.eventbus.impl.DefaultEventBus$HandlerEntry.close(DefaultEventBus.java:1119)
> at 
> org.vertx.java.core.impl.DefaultContext.runCloseHooks(DefaultContext.java:110)
> at 
> org.vertx.java.platform.impl.DefaultPlatformManager$23.run(DefaultPlatformManager.java:1855)
> at 
> org.vertx.java.core.impl.DefaultContext$3.run(DefaultContext.java:175)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
> at 
> io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
> at java.lang.Thread.run(Thread.java:745)
> Jun 07, 2016 10:52:39 AM com.hazelcast.core.LifecycleService
> INFO: [169.254.239.74]:5702 [dev] [3.2.3] Address[169.254.239.74]:5702 is 
> SHUTTING_DOWN
> Jun 07, 2016 10:52:39 AM org.vertx.java.core.logging.impl.JULLogDelegate error
> SEVERE: Exception in Java verticle
> java.util.concurrent.RejectedExecutionException: Task 
> org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor$1@2867fcb1 
> rejected from java.util.concurrent.ThreadPoolExecutor@42731816[Shutting down, 
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 4]
> at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2047)
> at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at 
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at 
> org.vertx.java.core.impl.OrderedExecutorFactory$OrderedExecutor.execute(OrderedExecutorFactory.java:111)
> at 
> org.vertx.java.core.impl.DefaultContext.executeOnOrderedWorkerExec(DefaultContext.java:156)
> at 
> 

[jira] [Resolved] (ARTEMIS-554) Some examples that run without user interaction are not part of the `examples` maven profile.

[Martyn Taylor (JIRA)]

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

Martyn Taylor resolved ARTEMIS-554.
---
   Resolution: Fixed
Fix Version/s: 1.4.0

> Some examples that run without user interaction are not part of the 
> `examples` maven profile.
> -
>
> Key: ARTEMIS-554
> URL: https://issues.apache.org/jira/browse/ARTEMIS-554
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Jiri Danek
>  Labels: examples
> Fix For: 1.4.0
>
>
> The following examples run without user intervention and can be added to the 
> `examples` maven profile, so that they are all executed by a simple `mvn 
> -Pexamples verify` command.
> * all {{protocols/openwire}} examples except {{chat}}
> * {{features/standard/ssl-enabled}}, because ARTEMIS-197 mentioned in comment 
> is already fixed
> * possibly also the vertx example, but that is currently failing to run for me



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)