[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958254#comment-15958254 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @clebertsuconic Just sent a discussion to dev list. :) > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958138#comment-15958138 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward you don't have to open a discuss for every simple fix you're going to make.. But the one you had here was certainly not simple. If you simplify the logic then you don't need one probably > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958069#comment-15958069 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @mtaylor @clebertsuconic guys thanks for the comments/suggestions. I'll try to simplify if it is possible. I think I'd better send out a discussion giving the details of how it is implemented before I change any code. Sorry for not having done it first, I've had too much assumptions. :) > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-826) MQTT with a long password field causes NPE exception
[
https://issues.apache.org/jira/browse/ARTEMIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957952#comment-15957952
]
Timothy Bish commented on ARTEMIS-826:
--
I took a look quickly as this rang a bell from an issue for ActiveMQ from way
back. The trouble here seems to be that the protocol detection code in Artemis
is expecting the layout of the CONNECT packet to always be the same but that
isn't the case in MQTT. The CONNECT command consists of a Fixed header,
followed by an encoded value which indicates the remaining length of the packet
and then the variable length header plus a possible payload section. The bit
that is not taken into account here is the 'remaining length' portion which can
be up to four bytes in length to indicate the length of the variable header +
the payload.
In the simpler cases Artemis receives a packet that looks something like "[16,
36, 0, 4, 77, 81, 84, 84]" where the last four bytes are "MQTT" (or MQIs for
3.1). However, if the password + username + everything else is large the value
of the remaining length gets bigger and spills over into more bytes at the
start of the command and you might see something like "[16, -126, 3, 0, 4, 77,
81, 84]" which breaks the current protocol checks.
It gets worse though in that if the length value reaches the four byte max then
you might see something like "[16, -126, -126, -126, 10, 0, 4, 77]" in which
case you can't decide if the protocol is MQTT 3.1.1 or 3.1 and really you can't
even tell it's MQTT at that point.
> 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] [Resolved] (ARTEMIS-1092) Validated user + AMQP throwing exception
[ https://issues.apache.org/jira/browse/ARTEMIS-1092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-1092. - Resolution: Fixed > Validated user + AMQP throwing exception > > > Key: ARTEMIS-1092 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1092 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1094) Replica can't connect to live via group-name when group size > 1
[ https://issues.apache.org/jira/browse/ARTEMIS-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957607#comment-15957607 ] ASF GitHub Bot commented on ARTEMIS-1094: - GitHub user jbertram opened a pull request: https://github.com/apache/activemq-artemis/pull/1175 ARTEMIS-1094 replica + group-name fix When a replica attempts to connect to a live server using a group-name and there are > 1 servers on the network using that group there is a chance it will fail because it doesn't keep track of all of the topology data it receives. This fix ensures that all the topology data from the cluster tracked until it is used and fails at which point it is discarded. You can merge this pull request into a Git repository by running: $ git pull https://github.com/jbertram/activemq-artemis ARTEMIS-1094 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1175.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 #1175 commit 0e5a643de516df31bde9a0a61719d05382b4c8eb Author: Justin Bertram Date: 2017-04-05T20:12:23Z ARTEMIS-1094 replica + group-name fix When a replica attempts to connect to a live server using a group-name and there are > 1 servers on the network using that group there is a chance it will fail because it doesn't keep track of all of the topology data it receives. This fix ensures that all the topology data from the cluster tracked until it is used and fails at which point it is discarded. > Replica can't connect to live via group-name when group size > 1 > > > Key: ARTEMIS-1094 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1094 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Justin Bertram >Assignee: Justin Bertram > Fix For: 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957602#comment-15957602 ] ASF GitHub Bot commented on ARTEMIS-1089: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1174 > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957601#comment-15957601 ] ASF subversion and git services commented on ARTEMIS-1089: -- Commit c767e93bf53f4ed51f7d771a2e5183b25ff08bf7 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=c767e93 ] ARTEMIS-1089 Simplifying smoke tests > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (AMQ-6641) Not able use Old data when we upgrade to new version
[ https://issues.apache.org/jira/browse/AMQ-6641?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish closed AMQ-6641. - Resolution: Invalid requests for support are better made on the users mailing list. > Not able use Old data when we upgrade to new version > > > Key: AMQ-6641 > URL: https://issues.apache.org/jira/browse/AMQ-6641 > Project: ActiveMQ > Issue Type: Bug > Components: JDBC >Affects Versions: 5.14.0 >Reporter: Ramakrishna K > > We have upgraded Activemq 5.10. 0 to 5.14.0. We are using Mysql. We are not > able to use old data that was stored by using Activemq 5.10.0 . I we use > empty db we will lose existing persistance subscribers details. Please > suggest me how use existing database with with new version of Activemq > Thanks , > Ramakrishna K -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (AMQ-6638) isHeaderValid doesn't log reasons
[ https://issues.apache.org/jira/browse/AMQ-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved AMQ-6638. --- Resolution: Fixed Assignee: Timothy Bish Fix Version/s: 5.14.5 5.15.0 > isHeaderValid doesn't log reasons > - > > Key: AMQ-6638 > URL: https://issues.apache.org/jira/browse/AMQ-6638 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Ben Boo >Assignee: Timothy Bish > Fix For: 5.15.0, 5.14.5 > > > AmqpWireFormat#isHeaderValid has four branches in which it returns 'false' == > 'not valid'. > There's no logging in any of these four cases. As a beginner user it's nearly > impossible to guess what exactly the problem is. > Some logging including reasons would go a long way, make things more > accessible, and save time. > Related items: > * > https://stackoverflow.com/questions/43038083/activemq-vs-amqp-net-lite-versions > * https://github.com/Azure/amqpnetlite/issues/201 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMQ-6638) isHeaderValid doesn't log reasons
[ https://issues.apache.org/jira/browse/AMQ-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957579#comment-15957579 ] ASF subversion and git services commented on AMQ-6638: -- Commit 6fe437a3d63f94da74f9bb169e8095198592ded5 in activemq's branch refs/heads/activemq-5.14.x from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=6fe437a ] https://issues.apache.org/jira/browse/AMQ-6638 Adds some additional logging to the connection validation code, adds some additional tests as well. (cherry picked from commit 0752d840b90a5acdb04410362fb16c943f09dc2f) > isHeaderValid doesn't log reasons > - > > Key: AMQ-6638 > URL: https://issues.apache.org/jira/browse/AMQ-6638 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Ben Boo > Fix For: 5.15.0, 5.14.5 > > > AmqpWireFormat#isHeaderValid has four branches in which it returns 'false' == > 'not valid'. > There's no logging in any of these four cases. As a beginner user it's nearly > impossible to guess what exactly the problem is. > Some logging including reasons would go a long way, make things more > accessible, and save time. > Related items: > * > https://stackoverflow.com/questions/43038083/activemq-vs-amqp-net-lite-versions > * https://github.com/Azure/amqpnetlite/issues/201 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMQ-6638) isHeaderValid doesn't log reasons
[ https://issues.apache.org/jira/browse/AMQ-6638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957577#comment-15957577 ] ASF subversion and git services commented on AMQ-6638: -- Commit 0752d840b90a5acdb04410362fb16c943f09dc2f in activemq's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=0752d84 ] https://issues.apache.org/jira/browse/AMQ-6638 Adds some additional logging to the connection validation code, adds some additional tests as well. > isHeaderValid doesn't log reasons > - > > Key: AMQ-6638 > URL: https://issues.apache.org/jira/browse/AMQ-6638 > Project: ActiveMQ > Issue Type: Improvement >Reporter: Ben Boo > > AmqpWireFormat#isHeaderValid has four branches in which it returns 'false' == > 'not valid'. > There's no logging in any of these four cases. As a beginner user it's nearly > impossible to guess what exactly the problem is. > Some logging including reasons would go a long way, make things more > accessible, and save time. > Related items: > * > https://stackoverflow.com/questions/43038083/activemq-vs-amqp-net-lite-versions > * https://github.com/Azure/amqpnetlite/issues/201 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARTEMIS-1094) Replica can't connect to live via group-name when group size > 1
Justin Bertram created ARTEMIS-1094: --- Summary: Replica can't connect to live via group-name when group size > 1 Key: ARTEMIS-1094 URL: https://issues.apache.org/jira/browse/ARTEMIS-1094 Project: ActiveMQ Artemis Issue Type: Bug Affects Versions: 2.0.0 Reporter: Justin Bertram Assignee: Justin Bertram Fix For: 2.next -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (ARTEMIS-826) MQTT with a long password field causes NPE exception
[
https://issues.apache.org/jira/browse/ARTEMIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957447#comment-15957447
]
Ram C edited comment on ARTEMIS-826 at 4/5/17 6:59 PM:
---
[~martyntaylor] : Here are the steps which I have simulated the same issue as
using the MQTTTest.java and MQTTTestSupport.java file.
Steps to recreate:
1. Update the MATTTestSupport > createMQTTTcpConnection method to pass username
and password (JW token)
private MQTT createMQTTTcpConnection(String clientId, boolean clean) throws
Exception {
MQTT mqtt = new MQTT();
mqtt.setConnectAttemptsMax(1);
mqtt.setReconnectAttemptsMax(0);
mqtt.setTracer(createTracer());
mqtt.setVersion("3.1.1");
mqtt.setUserName("test_user");
mqtt.setPassword("eyJhbGciOiJIUzUxMiJ9.eyJjcmVhdGVkIjoxNDc3NDg1NDc5OTEzLCJleHAiOjE0Nzc0ODcyNzksInV1aWQiOiI2NmVkNDc3Mi");
if (clientId != null) {
mqtt.setClientId(clientId);
}
mqtt.setCleanSession(clean);
mqtt.setHost("localhost", port);
return mqtt;
}
2. Compile and Run the MQTTTest.java > testResendMessageId method.
The validation was failed in MQTTProtocolManager > isProtocol method as the
array[4] != 77 when we were using JW token as password field.
Thanks!
was (Author: c.ramsubbu):
[~martyntaylor] : Here I simulated the same issue as using the MQTTTest.java
and MQTTTestSupport.java file.
Steps to recreate:
1. Update the MATTTestSupport > createMQTTTcpConnection method to pass username
and password (JW token)
private MQTT createMQTTTcpConnection(String clientId, boolean clean) throws
Exception {
MQTT mqtt = new MQTT();
mqtt.setConnectAttemptsMax(1);
mqtt.setReconnectAttemptsMax(0);
mqtt.setTracer(createTracer());
mqtt.setVersion("3.1.1");
mqtt.setUserName("test_user");
mqtt.setPassword("eyJhbGciOiJIUzUxMiJ9.eyJjcmVhdGVkIjoxNDc3NDg1NDc5OTEzLCJleHAiOjE0Nzc0ODcyNzksInV1aWQiOiI2NmVkNDc3Mi");
if (clientId != null) {
mqtt.setClientId(clientId);
}
mqtt.setCleanSession(clean);
mqtt.setHost("localhost", port);
return mqtt;
}
2. Compile and Run the MQTTTest.java > testResendMessageId method.
The validation was failed in MQTTProtocolManager > isProtocol method as the
array[4] != 77 when we were using JW token as password field.
Thanks!
> 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] [Commented] (ARTEMIS-826) MQTT with a long password field causes NPE exception
[
https://issues.apache.org/jira/browse/ARTEMIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957447#comment-15957447
]
Ram C commented on ARTEMIS-826:
---
[~martyntaylor] : Here I simulated the same issue as using the MQTTTest.java
and MQTTTestSupport.java file.
Steps to recreate:
1. Update the MATTTestSupport > createMQTTTcpConnection method to pass username
and password (JW token)
private MQTT createMQTTTcpConnection(String clientId, boolean clean) throws
Exception {
MQTT mqtt = new MQTT();
mqtt.setConnectAttemptsMax(1);
mqtt.setReconnectAttemptsMax(0);
mqtt.setTracer(createTracer());
mqtt.setVersion("3.1.1");
mqtt.setUserName("test_user");
mqtt.setPassword("eyJhbGciOiJIUzUxMiJ9.eyJjcmVhdGVkIjoxNDc3NDg1NDc5OTEzLCJleHAiOjE0Nzc0ODcyNzksInV1aWQiOiI2NmVkNDc3Mi");
if (clientId != null) {
mqtt.setClientId(clientId);
}
mqtt.setCleanSession(clean);
mqtt.setHost("localhost", port);
return mqtt;
}
2. Compile and Run the MQTTTest.java > testResendMessageId method.
The validation was failed in MQTTProtocolManager > isProtocol method as the
array[4] != 77 when we were using JW token as password field.
Thanks!
> 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] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[
https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957193#comment-15957193
]
ASF GitHub Bot commented on ARTEMIS-1025:
-
Github user franz1981 commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1119#discussion_r109967119
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnection.java
---
@@ -211,143 +251,203 @@ public void run() {
@Override
public ActiveMQBuffer createTransportBuffer(final int size) {
- return new
ChannelBufferWrapper(PooledByteBufAllocator.DEFAULT.directBuffer(size), true);
+ try {
+ return new
ChannelBufferWrapper(channel.alloc().directBuffer(size), true);
+ } catch (OutOfMemoryError oom) {
+ if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
+final long totalPendingWriteBytes =
batchBufferSize(this.channel, this.writeBufferHighWaterMark);
+ActiveMQClientLogger.LOGGER.trace("pendingWrites: [NETTY] -> "
+ totalPendingWriteBytes + "[EVENT LOOP] -> " +
pendingWritesOnEventLoopView.get() + " causes: " + oom.getMessage(), oom);
+ }
+ throw oom;
+ }
}
@Override
- public Object getID() {
+ public final Object getID() {
// TODO: Think of it
return channel.hashCode();
}
// This is called periodically to flush the batch buffer
@Override
- public void checkFlushBatchBuffer() {
- if (!batchingEnabled) {
- return;
- }
-
- if (writeLock.tryAcquire()) {
- try {
-if (batchBuffer != null && batchBuffer.readable()) {
- channel.writeAndFlush(batchBuffer.byteBuf());
-
- batchBuffer = createTransportBuffer(BATCHING_BUFFER_SIZE);
-}
- } finally {
-writeLock.release();
+ public final void checkFlushBatchBuffer() {
+ if (this.batchingEnabled) {
+ //perform the flush only if necessary
+ final int batchBufferSize = batchBufferSize(this.channel,
this.writeBufferHighWaterMark);
+ if (batchBufferSize > 0) {
+this.channel.flush();
}
}
}
@Override
- public void write(final ActiveMQBuffer buffer) {
+ public final void write(final ActiveMQBuffer buffer) {
write(buffer, false, false);
}
@Override
- public void write(ActiveMQBuffer buffer, final boolean flush, final
boolean batched) {
+ public final void write(ActiveMQBuffer buffer, final boolean flush,
final boolean batched) {
write(buffer, flush, batched, null);
}
@Override
- public void write(ActiveMQBuffer buffer,
- final boolean flush,
- final boolean batched,
- final ChannelFutureListener futureListener) {
-
- try {
- writeLock.acquire();
-
- try {
-if (batchBuffer == null && batchingEnabled && batched &&
!flush) {
- // Lazily create batch buffer
-
- batchBuffer =
ActiveMQBuffers.dynamicBuffer(BATCHING_BUFFER_SIZE);
-}
-
-if (batchBuffer != null) {
- batchBuffer.writeBytes(buffer, 0, buffer.writerIndex());
-
- if (batchBuffer.writerIndex() >= BATCHING_BUFFER_SIZE ||
!batched || flush) {
- // If the batch buffer is full or it's flush param or
not batched then flush the buffer
-
- buffer = batchBuffer;
- } else {
- return;
- }
-
- if (!batched || flush) {
- batchBuffer = null;
- } else {
- // Create a new buffer
+ public final boolean blockUntilWritable(final int requiredCapacity,
final long timeout, final TimeUnit timeUnit) {
+ final boolean isAllowedToBlock = isAllowedToBlock();
+ if (!isAllowedToBlock) {
+ return canWrite(requiredCapacity);
+ } else {
+ final long timeoutNanos = timeUnit.toNanos(timeout);
+ final long deadline = System.nanoTime() + timeoutNanos;
+ //choose wait time unit size
+ final long parkNanos;
+ //if is requested to wait more than a millisecond than we could
use
+ if (timeoutNanos >= 1_000_000L) {
+parkNanos = 100_000L;
+ } else {
+//reduce it doesn't make sense, only a spin loop could be
enough precise with the most
[jira] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[ https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957194#comment-15957194 ] ASF GitHub Bot commented on ARTEMIS-1025: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1119 @clebertsuconic Yes, I'm planning to use it there! > OutOfDirectMemoryError raised from Netty > > > Key: ARTEMIS-1025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1025 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro > > If you send and receive a lot of messages in short time to Artemis via Netty > connector, the OutOfDirectMemoryError exception is thrown from the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957065#comment-15957065 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward another reason to simplify the patch then. Make it simple please! > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[ https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957053#comment-15957053 ] ASF GitHub Bot commented on ARTEMIS-1025: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1119 @franz1981 you will have to call blockUntilWritable on the Large Message Producer, right? > OutOfDirectMemoryError raised from Netty > > > Key: ARTEMIS-1025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1025 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro > > If you send and receive a lot of messages in short time to Artemis via Netty > connector, the OutOfDirectMemoryError exception is thrown from the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[
https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957046#comment-15957046
]
ASF GitHub Bot commented on ARTEMIS-1025:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1119#discussion_r109950618
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnection.java
---
@@ -211,143 +251,203 @@ public void run() {
@Override
public ActiveMQBuffer createTransportBuffer(final int size) {
- return new
ChannelBufferWrapper(PooledByteBufAllocator.DEFAULT.directBuffer(size), true);
+ try {
+ return new
ChannelBufferWrapper(channel.alloc().directBuffer(size), true);
+ } catch (OutOfMemoryError oom) {
+ if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
+final long totalPendingWriteBytes =
batchBufferSize(this.channel, this.writeBufferHighWaterMark);
+ActiveMQClientLogger.LOGGER.trace("pendingWrites: [NETTY] -> "
+ totalPendingWriteBytes + "[EVENT LOOP] -> " +
pendingWritesOnEventLoopView.get() + " causes: " + oom.getMessage(), oom);
+ }
+ throw oom;
+ }
}
@Override
- public Object getID() {
+ public final Object getID() {
// TODO: Think of it
return channel.hashCode();
}
// This is called periodically to flush the batch buffer
@Override
- public void checkFlushBatchBuffer() {
- if (!batchingEnabled) {
- return;
- }
-
- if (writeLock.tryAcquire()) {
- try {
-if (batchBuffer != null && batchBuffer.readable()) {
- channel.writeAndFlush(batchBuffer.byteBuf());
-
- batchBuffer = createTransportBuffer(BATCHING_BUFFER_SIZE);
-}
- } finally {
-writeLock.release();
+ public final void checkFlushBatchBuffer() {
+ if (this.batchingEnabled) {
+ //perform the flush only if necessary
+ final int batchBufferSize = batchBufferSize(this.channel,
this.writeBufferHighWaterMark);
+ if (batchBufferSize > 0) {
+this.channel.flush();
}
}
}
@Override
- public void write(final ActiveMQBuffer buffer) {
+ public final void write(final ActiveMQBuffer buffer) {
write(buffer, false, false);
}
@Override
- public void write(ActiveMQBuffer buffer, final boolean flush, final
boolean batched) {
+ public final void write(ActiveMQBuffer buffer, final boolean flush,
final boolean batched) {
write(buffer, flush, batched, null);
}
@Override
- public void write(ActiveMQBuffer buffer,
- final boolean flush,
- final boolean batched,
- final ChannelFutureListener futureListener) {
-
- try {
- writeLock.acquire();
-
- try {
-if (batchBuffer == null && batchingEnabled && batched &&
!flush) {
- // Lazily create batch buffer
-
- batchBuffer =
ActiveMQBuffers.dynamicBuffer(BATCHING_BUFFER_SIZE);
-}
-
-if (batchBuffer != null) {
- batchBuffer.writeBytes(buffer, 0, buffer.writerIndex());
-
- if (batchBuffer.writerIndex() >= BATCHING_BUFFER_SIZE ||
!batched || flush) {
- // If the batch buffer is full or it's flush param or
not batched then flush the buffer
-
- buffer = batchBuffer;
- } else {
- return;
- }
-
- if (!batched || flush) {
- batchBuffer = null;
- } else {
- // Create a new buffer
+ public final boolean blockUntilWritable(final int requiredCapacity,
final long timeout, final TimeUnit timeUnit) {
+ final boolean isAllowedToBlock = isAllowedToBlock();
+ if (!isAllowedToBlock) {
+ return canWrite(requiredCapacity);
+ } else {
+ final long timeoutNanos = timeUnit.toNanos(timeout);
+ final long deadline = System.nanoTime() + timeoutNanos;
+ //choose wait time unit size
+ final long parkNanos;
+ //if is requested to wait more than a millisecond than we could
use
+ if (timeoutNanos >= 1_000_000L) {
+parkNanos = 100_000L;
+ } else {
+//reduce it doesn't make sense, only a spin loop could be
enough precise with the
[jira] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[
https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957044#comment-15957044
]
ASF GitHub Bot commented on ARTEMIS-1025:
-
Github user clebertsuconic commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1119#discussion_r109950463
--- Diff:
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnection.java
---
@@ -211,143 +251,203 @@ public void run() {
@Override
public ActiveMQBuffer createTransportBuffer(final int size) {
- return new
ChannelBufferWrapper(PooledByteBufAllocator.DEFAULT.directBuffer(size), true);
+ try {
+ return new
ChannelBufferWrapper(channel.alloc().directBuffer(size), true);
+ } catch (OutOfMemoryError oom) {
+ if (ActiveMQClientLogger.LOGGER.isTraceEnabled()) {
+final long totalPendingWriteBytes =
batchBufferSize(this.channel, this.writeBufferHighWaterMark);
+ActiveMQClientLogger.LOGGER.trace("pendingWrites: [NETTY] -> "
+ totalPendingWriteBytes + "[EVENT LOOP] -> " +
pendingWritesOnEventLoopView.get() + " causes: " + oom.getMessage(), oom);
+ }
+ throw oom;
+ }
}
@Override
- public Object getID() {
+ public final Object getID() {
// TODO: Think of it
return channel.hashCode();
}
// This is called periodically to flush the batch buffer
@Override
- public void checkFlushBatchBuffer() {
- if (!batchingEnabled) {
- return;
- }
-
- if (writeLock.tryAcquire()) {
- try {
-if (batchBuffer != null && batchBuffer.readable()) {
- channel.writeAndFlush(batchBuffer.byteBuf());
-
- batchBuffer = createTransportBuffer(BATCHING_BUFFER_SIZE);
-}
- } finally {
-writeLock.release();
+ public final void checkFlushBatchBuffer() {
+ if (this.batchingEnabled) {
+ //perform the flush only if necessary
+ final int batchBufferSize = batchBufferSize(this.channel,
this.writeBufferHighWaterMark);
+ if (batchBufferSize > 0) {
+this.channel.flush();
}
}
}
@Override
- public void write(final ActiveMQBuffer buffer) {
+ public final void write(final ActiveMQBuffer buffer) {
write(buffer, false, false);
}
@Override
- public void write(ActiveMQBuffer buffer, final boolean flush, final
boolean batched) {
+ public final void write(ActiveMQBuffer buffer, final boolean flush,
final boolean batched) {
write(buffer, flush, batched, null);
}
@Override
- public void write(ActiveMQBuffer buffer,
- final boolean flush,
- final boolean batched,
- final ChannelFutureListener futureListener) {
-
- try {
- writeLock.acquire();
-
- try {
-if (batchBuffer == null && batchingEnabled && batched &&
!flush) {
- // Lazily create batch buffer
-
- batchBuffer =
ActiveMQBuffers.dynamicBuffer(BATCHING_BUFFER_SIZE);
-}
-
-if (batchBuffer != null) {
- batchBuffer.writeBytes(buffer, 0, buffer.writerIndex());
-
- if (batchBuffer.writerIndex() >= BATCHING_BUFFER_SIZE ||
!batched || flush) {
- // If the batch buffer is full or it's flush param or
not batched then flush the buffer
-
- buffer = batchBuffer;
- } else {
- return;
- }
-
- if (!batched || flush) {
- batchBuffer = null;
- } else {
- // Create a new buffer
+ public final boolean blockUntilWritable(final int requiredCapacity,
final long timeout, final TimeUnit timeUnit) {
+ final boolean isAllowedToBlock = isAllowedToBlock();
+ if (!isAllowedToBlock) {
+ return canWrite(requiredCapacity);
+ } else {
+ final long timeoutNanos = timeUnit.toNanos(timeout);
+ final long deadline = System.nanoTime() + timeoutNanos;
+ //choose wait time unit size
+ final long parkNanos;
+ //if is requested to wait more than a millisecond than we could
use
+ if (timeoutNanos >= 1_000_000L) {
+parkNanos = 100_000L;
+ } else {
+//reduce it doesn't make sense, only a spin loop could be
enough precise with the
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15957037#comment-15957037 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @mtaylor ok. BTW I didn't change the send part at all. My thought is that sending is always targeted to an address, not a queue, so it doesn't make sense to reference an address by FQQN. > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956992#comment-15956992 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward Could you split this into two patches. The consume should be pretty easy. If the subscribe packet contains a FQQN then parse the address, then lookup the queue. The send is harder but we can resolve that later. Cheers > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956993#comment-15956993 ] ASF GitHub Bot commented on ARTEMIS-1089: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/1174 ARTEMIS-1089 Simplifying smoke tests You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis test Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/1174.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 #1174 commit 4eabc89337565c6b342b00d7efc03090816ba67f Author: Clebert Suconic Date: 2017-04-05T14:25:28Z ARTEMIS-1089 Simplifying smoke tests > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (AMQ-5960) Durable subscriber pendingQueueSize wrong after force shutdown of the broker
[ https://issues.apache.org/jira/browse/AMQ-5960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956982#comment-15956982 ] Justin Reock commented on AMQ-5960: --- I don't believe this issue is fixed, it is still reproducible in 5.14.4. Same test case, create durable subs with persistent messages, connect consumers and start draining. Hard-kill the broker and restart it, allow consumers to drain. There will be "lingering" pendingQueueSize counts, although there is no actual message loss. KahaDB just doesn't update the ack position. Tested with LevelDB and cannot recreate, this only happens with Kaha. > Durable subscriber pendingQueueSize wrong after force shutdown of the broker > > > Key: AMQ-5960 > URL: https://issues.apache.org/jira/browse/AMQ-5960 > Project: ActiveMQ > Issue Type: Bug >Affects Versions: 5.12.0 >Reporter: Dejan Bosanac >Assignee: Dejan Bosanac > Fix For: 5.13.0 > > > The main reason for this is that ackPositions (based on which > pendingQueueSize is calculated) is not rebuilt correctly during index recover. > To reproduce it: > 1. Start the broker > 2. Start producer and durable consumer on a topic, making a load > 3. Kill the broker with -9 > 4. Restart the broker > The durable consumer pendingQueueSize is off by one and is never corrected -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956943#comment-15956943 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @mtaylor is it possible to use the existing SimpleAddressManager or WildcardAddressManager and just add a new binding for "address::foo" -> QueueBindingImpl(name="foo", address="address") ? Let me think about it... > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956939#comment-15956939 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @clebertsuconic fyi https://github.com/apache/activemq-artemis/blob/master/docs/user-manual/en/address-model.md#fully-qualified-queue-names > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956940#comment-15956940 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward @clebertsuconic Just to clarify Clebert is referring to the implementation not the feature. The feature is required. @gaohoward is it possible to use the existing SimpleAddressManager or WildcardAddressManager and just add a new binding for "address::foo" -> QueueBindingImpl(name="foo", address="address") ? > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956935#comment-15956935 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @clebertsuconic This is already in user's manual, I thought it just missed the implementation. But anyway I couldn't send out a discussion. > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956889#comment-15956889 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward for something like this you should have talked to us through a DISCUSS thread, or talked about some design first... There's WildcardConfiguration already... this is a big change, and I don't like it much.. it adds a complext piece of a referenceCounting on this Key, plus some concatenations to lookup for Addresses... I'm really concerned about letting this change go in... Can't we have a simpler change.. perhaps use the WildcardAddressManager in any way? what it is needed that is not covered by that already? > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956811#comment-15956811 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user gaohoward commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 Yes OpenWire still referring to the queue name, in JMS terms. Not sure what you meant by "ANYCAST address name". My understanding is that when you send messages you send to an address of anycast and/or multicast route type, is that correct? > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1025) OutOfDirectMemoryError raised from Netty
[ https://issues.apache.org/jira/browse/ARTEMIS-1025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956806#comment-15956806 ] ASF GitHub Bot commented on ARTEMIS-1025: - Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1119 @clebertsuconic I've simplified further the connection usage adding only a single method to it: [Connection::blockUntilWritable](https://github.com/franz1981/activemq-artemis/blob/95ef25d17eb29910553153caff743f215c3e69be/artemis-core-client/src/main/java/org/apache/activemq/artemis/spi/core/remoting/Connection.java#L59). It is meant to be used when is necessary to block (if allowed by the caller thread) until the Connection's write buffer will have enough room to buffer the request. In the NettyConnection implementation it will choose to block only if not in the event loop and considering the Netty write buffer size plus the pending writes on the event loop too. > OutOfDirectMemoryError raised from Netty > > > Key: ARTEMIS-1025 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1025 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Reporter: Francesco Nigro >Assignee: Francesco Nigro > > If you send and receive a lot of messages in short time to Artemis via Netty > connector, the OutOfDirectMemoryError exception is thrown from the client. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956779#comment-15956779 ] ASF GitHub Bot commented on ARTEMIS-1089: - Github user clebertsuconic closed the pull request at: https://github.com/apache/activemq-artemis/pull/1168 > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1093) Full qualified queue name support
[ https://issues.apache.org/jira/browse/ARTEMIS-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956746#comment-15956746 ] ASF GitHub Bot commented on ARTEMIS-1093: - Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/1172 @gaohoward Howard, I am a bit confused by your commit message. Since the new addressing change, clients should now refer to an ANYCAST address name, not the queue name. Do this commit change the behaviour here or was OpenWire still referring to the queue name? > Full qualified queue name support > - > > Key: ARTEMIS-1093 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1093 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.0.0 >Reporter: Howard Gao >Assignee: Howard Gao > Fix For: 2.next > > > Broker should support full qualified queue names (FQQN) as well as bare queue > names. This means when clients access to a queue they have two equivalent > ways to do so. One way is by queue names and the other is by FQQN (i.e. > address::qname) names. When accessing a queue by its bare name, it is > required that the name should be unique across all addresses. > Otherwise a warning is given and client should use FQQN instead. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956737#comment-15956737 ] ASF GitHub Bot commented on ARTEMIS-1089: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/1171 > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956736#comment-15956736 ] ASF subversion and git services commented on ARTEMIS-1089: -- Commit dd27fb587f1862b74dcf1c72115022351ca1ed67 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=dd27fb5 ] ARTEMIS-1089 Moving smoke tests under ./tests/smoke-tests This is moving the smoke tests creates as part of the relication tests. They are also now based on junit tests. And to support starting servers I am exposing basedir to unit tests in general. > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956735#comment-15956735 ] ASF GitHub Bot commented on ARTEMIS-1089: - Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/1171 @clebertsuconic thanks > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-1089) Backup sync-up is slow when paging
[ https://issues.apache.org/jira/browse/ARTEMIS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956730#comment-15956730 ] ASF GitHub Bot commented on ARTEMIS-1089: - Github user mtaylor commented on the issue: https://github.com/apache/activemq-artemis/pull/1168 @clebertsuconic I've merged this. Can you manually close please. > Backup sync-up is slow when paging > -- > > Key: ARTEMIS-1089 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1089 > Project: ActiveMQ Artemis > Issue Type: Bug >Affects Versions: 1.5.4, 2.0.0 >Reporter: clebert suconic >Assignee: clebert suconic > Fix For: 1.5.5, 2.next > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (AMQ-6646) default blob strategy error reporting should include url
[ https://issues.apache.org/jira/browse/AMQ-6646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully resolved AMQ-6646. - Resolution: Fixed > default blob strategy error reporting should include url > > > Key: AMQ-6646 > URL: https://issues.apache.org/jira/browse/AMQ-6646 > Project: ActiveMQ > Issue Type: Bug > Components: JMS client >Affects Versions: 5.14.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Minor > Fix For: 5.15.0 > > > Default blob upload strategy can do a little better at reporting errors by > including the url such that it is clear what url in in the mix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (ARTEMIS-826) MQTT with a long password field causes NPE exception
[
https://issues.apache.org/jira/browse/ARTEMIS-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15956559#comment-15956559
]
Martyn Taylor commented on ARTEMIS-826:
---
This has been raised by another user. I'll aim to prioritise. Is there any
chance someone experiencing the issue could create a unit test? It would speed
things up. There are a bunch of tests in the MQTTTest class that use the Fuse
client, alternatively, look at the Paho test in the same directory.
> 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)
