[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180971622
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ChannelImpl.java
 ---
@@ -511,22 +511,24 @@ public void close() {
public void transferConnection(final CoreRemotingConnection 
newConnection) {
   // Needs to synchronize on the connection to make sure no packets 
from
   // the old connection get processed after transfer has occurred
-  synchronized (connection.getTransferLock()) {
- connection.removeChannel(id);
+  if (connection != null) {
--- End diff --

Well, it is null-checked few lines bellow so it confued me.


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1794) Confusion when auto removing a queue

[Lionel Cons (JIRA)]

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

Lionel Cons commented on ARTEMIS-1794:
--

The use case is the following.

We have many ActiveMQ 5 STOMP clients that use topics and queues.

In order to ease the transition from ActiveMQ 5 to Artemis, we would like to 
avoid having to change the destination names used by all these clients. So we 
would need to have {{/topic/foo}} behaving like a topic and {{/queue/foo}} 
behaving like a queue, like we have now.

Some destination names are dynamic and not known in advance so they cannot be 
declared beforehand in {{broker.xml}}.

The acceptor prefixes were a perfect match for this use case...

Since a topic named {{foo}} is completely independent from a queue named 
{{foo}}, maybe they should not share the same address.

What about not stripping the acceptor prefixes to derive the address names?

> Confusion when auto removing a queue
> 
>
> Key: ARTEMIS-1794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1794
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm using the following settings to try to mimic ActiveMQ 5 STOMP destination 
> handling:
> {code}
>  name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true;anycastPrefix=/queue/;multicastPrefix=/topic/
> {code}
> This works as expected in most situations.
> However, when subscribing to a queue (via {{destination:/queue/foo}}) and 
> sending a message to an eponymous topic ({{destination:/topic/foo}}) Artemis 
> reports a fatal error:
> {code}
> AMQ119209 Can't remove routing type ANYCAST, queues exists for address foo. 
> Please delete queues before removing this routing type.
> {code}
> I guess this happens when it tries to auto delete things.
> Doing the opposite (subscribing to the queue and sending a message to the 
> topic), I get the same kind of error:
> {code}
> AMQ119209 Can't remove routing type MULTICAST, queues exists for address foo. 
> Please delete queues before removing this routing type.
> {code}



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

[jira] [Commented] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Lionel Cons (JIRA)]

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

Lionel Cons commented on ARTEMIS-1802:
--

Unfortunately, the solution you propose does not cover what ActiveMQ 5 gives. 
First, I need to be able to subscribe to the topic to receive messages without 
interfering with the queues. Then, I need to be able to send messages directly 
to one queue without interfering with the other.

Regarding naming, the bindings seem to be an internal thing and not something a 
user should know and worry about, as opposed to diverts and queues that are 
named and defined in the broker configuration file. Would it make sense to lift 
this naming restriction to better hide the internal implementation?

For instance, a divert named {{foo}} could be mapped to a binding named 
{{divert:foo}} while a queue named {{foo}} could be mapped to a binding named 
{{queue:foo}}.

> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code:xml}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



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

[jira] [Commented] (AMQ-6930) bin/activemq should allow stdout/stderr to some file instead of /dev/null for daemon mode

[Alvin Lin (JIRA)]

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

Alvin Lin commented on AMQ-6930:


There is actually one more thing regarding this change. We may need to add 
documentation on the things to be aware of when setting ACTIVEMQ_OUT. 

Since ActiveMQ by default configures a console appender for log, so when an 
user configures ACTIVEMQ_OUT all the logs logged to activemq.log will also be 
logged to $ACTIVEMQ_OUT. So maybe we want to document this and mention about 
they can disable the ConsoleAppender in log4j.properties; also, the document 
should probably mention about using logrotate to rotate $ACTIVEMQ_OUT and that 
logrotate should use "copy truncate". 

I am more than happy to contribute to the documentation if I can get some lead 
on the source of the ActiveMQ website and the documentation release process; we 
definitely don't want to expose the documentation for ACTIVEMQ_OUT before it's 
release :)

> bin/activemq should allow stdout/stderr to some file instead of /dev/null for 
> daemon mode
> -
>
> Key: AMQ-6930
> URL: https://issues.apache.org/jira/browse/AMQ-6930
> Project: ActiveMQ
>  Issue Type: Wish
>Affects Versions: 5.15.0, 5.15.1, 5.15.2, 5.15.3
>Reporter: Alvin Lin
>Priority: Major
> Fix For: 5.16.0, 5.15.4
>
>
> if I do "bin/activemq start" the ActiveMQ process is started with 
> stdout/stdin redirected to /dev/null. 
> This makes it hard to debug issue like out of memory error because we can't 
> see any log, for example, when the JVM flag "ExitOnOutOfMemoryError" is 
> turned on. 



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

[jira] [Closed] (ARTEMIS-1790) Improve Topology Member Finding

[Howard Gao (JIRA)]

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

Howard Gao closed ARTEMIS-1790.
---
Resolution: Fixed

> Improve Topology Member Finding
> ---
>
> Key: ARTEMIS-1790
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1790
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.5.1
>
>
> When finding out if a connector belong to a target node it compares the whole 
> parameter map which is not necessary. Also in understanding the connector the 
> best place is to delegate it to the corresponding remoting connection who 
> understands it. (e.g. INVMConnection knows whether the connector belongs to a 
> target node by checking it's serverID only. The netty ones only need to match 
> host and port, and understanding that localhost and 127.0.0.1 are same thing).



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

[jira] [Commented] (ARTEMIS-1740) Add support for regex based certificate authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1740:
-

Github user jbertram commented on the issue:

https://github.com/apache/activemq-artemis/pull/2011
  
This looks good except for a few things:

- I would rather not have an additional file for the regex properties. I 
think it would be better to instead denote the regex in the normal user 
properties file using the traditional forward slashes (as described in the 
JIRA).
- There's no documentation. The new functionality should be documented in 
docs/user-manual/en/security.md.
- I'd like to see an integration test added to 
{{org.apache.activemq.artemis.tests.integration.security.SecurityTest}}. 
There's several tests in there already which test cert-based login.


> Add support for regex based certificate authentication
> --
>
> Key: ARTEMIS-1740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Priority: Major
>
> The current certificate authentication module 
> ({{TextFileCertificateLoginModule}}) uses a file mapping user names to DNs.
> In some cases, the list of known DNs can be large and dynamic. This is the 
> case for instance when using host certificates.
> Host certificates could be very dynamic (when new virtual machines get 
> created) while keeping a fixed structure such as {{CN=hostxyz.acme.org, 
> OU=computers, DC=acme, DC=org}}. It is impractical to generate all the 
> possible DNs and feed this to Artemis.
> It would be very useful to have regular expression based certificate 
> authentication. With the example above, we could have a single line:
> {quote}
> acme.computers=/^CN=\w+\.acme\.org, OU=computers, DC=acme, DC=org$/
> {quote}



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180859389
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ---
@@ -2712,6 +2712,10 @@ private Message makeCopy(final MessageReference ref, 
final boolean expiry) throw
private Message makeCopy(final MessageReference ref,
 final boolean expiry,
 final boolean copyOriginalHeaders) throws 
Exception {
+  if (ref == null) {
+ return null;
--- End diff --

I would actually throw an Exception.. you're not supposed to make a copy of 
a ref == null.

it's a valid assertion, but I would actually make it throw 
NullPointerException  here. (Or a chosen exception).


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180858486
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ChannelImpl.java
 ---
@@ -511,22 +511,24 @@ public void close() {
public void transferConnection(final CoreRemotingConnection 
newConnection) {
   // Needs to synchronize on the connection to make sure no packets 
from
   // the old connection get processed after transfer has occurred
-  synchronized (connection.getTransferLock()) {
- connection.removeChannel(id);
+  if (connection != null) {
--- End diff --

same thing here.. how connection would be null?


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180858361
  
--- Diff: 
artemis-core-client/src/main/java/org/apache/activemq/artemis/core/protocol/core/impl/ChannelImpl.java
 ---
@@ -380,7 +380,7 @@ public Packet sendBlocking(final Packet packet,
 
 connection.getTransportConnection().write(buffer, false, 
false);
 
-long toWait = connection.getBlockingCallTimeout();
--- End diff --

Looking at the code, I can't see how connection will ever be null here..  I 
think you should remove this one...

For instance... the very same connection was used before within a lock.. 
what would issue a NPE a lot earlier than here.

I don't see how connection could ever be null.


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180859972
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ---
@@ -2727,7 +2731,7 @@ private Message makeCopy(final MessageReference ref,
   Message copy = message.copy(newID);
 
   if (copyOriginalHeaders) {
- copy.referenceOriginalMessage(message, ref != null ? 
ref.getQueue().getName().toString() : null);
+ copy.referenceOriginalMessage(message, 
ref.getQueue().getName().toString());
--- End diff --

keep it ! :) nice one!


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180859106
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/paging/cursor/impl/PageSubscriptionImpl.java
 ---
@@ -205,7 +205,7 @@ public PageSubscriptionCounter getCounter() {
 */
@Override
public boolean reloadPageCompletion(PagePosition position) throws 
Exception {
-  if (!pageStore.checkPageFileExists((int)position.getPageNr())) {
+  if (pageStore != null && 
!pageStore.checkPageFileExists((int)position.getPageNr())) {
--- End diff --

pageStore is final.. it will never be null


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1790) Improve Topology Member Finding

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1790:
-

Github user asfgit closed the pull request at:

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


> Improve Topology Member Finding
> ---
>
> Key: ARTEMIS-1790
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1790
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.5.1
>
>
> When finding out if a connector belong to a target node it compares the whole 
> parameter map which is not necessary. Also in understanding the connector the 
> best place is to delegate it to the corresponding remoting connection who 
> understands it. (e.g. INVMConnection knows whether the connector belongs to a 
> target node by checking it's serverID only. The netty ones only need to match 
> host and port, and understanding that localhost and 127.0.0.1 are same thing).



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

[jira] [Commented] (ARTEMIS-1790) Improve Topology Member Finding

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1790 Improve Topology Member Finding

When finding out if a connector belong to a target node it compares
the whole parameter map which is not necessary. Also in understanding
the connector the best place is to delegate it to the corresponding
remoting connection who understands it. (e.g. INVMConnection knows
whether the connector belongs to a target node by checking it's
serverID only. The netty ones only need to match host and port, and
understanding that localhost and 127.0.0.1 are same thing).


> Improve Topology Member Finding
> ---
>
> Key: ARTEMIS-1790
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1790
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>  Components: Broker
>Affects Versions: 2.5.0
>Reporter: Howard Gao
>Assignee: Howard Gao
>Priority: Major
> Fix For: 2.5.1
>
>
> When finding out if a connector belong to a target node it compares the whole 
> parameter map which is not necessary. Also in understanding the connector the 
> best place is to delegate it to the corresponding remoting connection who 
> understands it. (e.g. INVMConnection knows whether the connector belongs to a 
> target node by checking it's serverID only. The netty ones only need to match 
> host and port, and understanding that localhost and 127.0.0.1 are same thing).



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

[jira] [Commented] (ARTEMIS-1740) Add support for regex based certificate authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1740:
-

Github user clebertsuconic commented on the issue:

https://github.com/apache/activemq-artemis/pull/2011
  
@jbertram can you look into this one? you have more miles on security than 
I do. :) 


> Add support for regex based certificate authentication
> --
>
> Key: ARTEMIS-1740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Priority: Major
>
> The current certificate authentication module 
> ({{TextFileCertificateLoginModule}}) uses a file mapping user names to DNs.
> In some cases, the list of known DNs can be large and dynamic. This is the 
> case for instance when using host certificates.
> Host certificates could be very dynamic (when new virtual machines get 
> created) while keeping a fixed structure such as {{CN=hostxyz.acme.org, 
> OU=computers, DC=acme, DC=org}}. It is impractical to generate all the 
> possible DNs and feed this to Artemis.
> It would be very useful to have regular expression based certificate 
> authentication. With the example above, we could have a single line:
> {quote}
> acme.computers=/^CN=\w+\.acme\.org, OU=computers, DC=acme, DC=org$/
> {quote}



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

[jira] [Commented] (ARTEMIS-1794) Confusion when auto removing a queue

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1794:
-

What's happening is that when the acceptor uses 
{{anycastPrefix=/queue/;multicastPrefix=/topic/}} and a STOMP client subscribes 
to {{/queue/foo}} the STOMP protocol head will create an {{ANYCAST}} address 
{{foo}} and an {{ANYCAST}} queue {{foo}}. Then when a STOMP client attempts to 
send a message to {{/topic/foo}} the broker will try to update the {{ANYCAST}} 
address to be {{MULTICAST}} which results in the error. There is a related bug 
here because the prefix isn't being stripped properly when looking up the 
address. However, even after that is fixed the broker will still throw an error 
in this case because the client is attempting to send a {{MULTICAST}} message 
to an {{ANYCAST}} address. If this restriction was removed the STOMP client's 
send operation could complete, but the broker still wouldn't route the message 
and it would be silently discarded (probably confusing the user).

Can you clarify your use-case here? Perhaps the broker provides the 
functionality you're looking for in a different way.

> Confusion when auto removing a queue
> 
>
> Key: ARTEMIS-1794
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1794
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: STOMP
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm using the following settings to try to mimic ActiveMQ 5 STOMP destination 
> handling:
> {code}
>  name="stomp">tcp://0.0.0.0:61613?tcpSendBufferSize=1048576;tcpReceiveBufferSize=1048576;protocols=STOMP;useEpoll=true;anycastPrefix=/queue/;multicastPrefix=/topic/
> {code}
> This works as expected in most situations.
> However, when subscribing to a queue (via {{destination:/queue/foo}}) and 
> sending a message to an eponymous topic ({{destination:/topic/foo}}) Artemis 
> reports a fatal error:
> {code}
> AMQ119209 Can't remove routing type ANYCAST, queues exists for address foo. 
> Please delete queues before removing this routing type.
> {code}
> I guess this happens when it tries to auto delete things.
> Doing the opposite (subscribing to the queue and sending a message to the 
> topic), I get the same kind of error:
> {code}
> AMQ119209 Can't remove routing type MULTICAST, queues exists for address foo. 
> Please delete queues before removing this routing type.
> {code}



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

[jira] [Updated] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1800:

Fix Version/s: (was: 2.6.0)
   2.5.1

> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 2.5.1
>
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Resolved] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon resolved ARTEMIS-1800.
-
   Resolution: Fixed
Fix Version/s: 2.6.0

> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
> Fix For: 2.6.0
>
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Commented] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1800:
-

Github user asfgit closed the pull request at:

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


> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Commented] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[ASF subversion and git services (JIRA)]

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

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

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

ARTEMIS-1800 - Fix metrics decrement on scheduled message cancel

The queue metrics were being decremented improperly because on iteration
over the cancelled scheduled messages because the flag for 
fromMessageReferences was not
set to false. Setting the flag to false skips over the metrics update
which is what we want as the scheduled messages were never added to the
message references in the first place so the metrics don't need updating


> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Commented] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1800:
-

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

https://github.com/apache/activemq-artemis/pull/2009#discussion_r180777030
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/QueueControlTest.java
 ---
@@ -2510,6 +2510,39 @@ public void testSendMessage() throws Exception {
   Assert.assertEquals(new String(body), "theBody");
}
 
+   @Test
+   public void testGetScheduledCountOnRemove() throws Exception {
+  long delay = Integer.MAX_VALUE;
+  SimpleString address = RandomUtil.randomSimpleString();
+  SimpleString queue = RandomUtil.randomSimpleString();
+
+  session.createQueue(address, RoutingType.MULTICAST, queue, null, 
durable);
+
+  QueueControl queueControl = createManagementControl(address, queue);
+  Assert.assertEquals(0, queueControl.getScheduledCount());
+
+  Field queueMemorySizeField = 
QueueImpl.class.getDeclaredField("queueMemorySize");
+  queueMemorySizeField.setAccessible(true);
+  final LocalQueueBinding binding = (LocalQueueBinding) 
server.getPostOffice().getBinding(queue);
+  Queue q = binding.getQueue();
+  AtomicInteger queueMemorySize1 = (AtomicInteger) 
queueMemorySizeField.get(q);
+  assertTrue(queueMemorySize1.get() == 0);
+
+  ClientProducer producer = session.createProducer(address);
+  ClientMessage message = session.createMessage(durable);
+  message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
System.currentTimeMillis() + delay);
+  producer.send(message);
+
+  queueControl.removeAllMessages();
+
+  Assert.assertEquals(0, queueControl.getMessageCount());
--- End diff --

ok.. I will just merge it


> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Updated] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Justin Bertram (JIRA)]

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

Justin Bertram updated ARTEMIS-1802:

Description: 
I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
(http://activemq.apache.org/virtual-destinations.html). The use case is a 
single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).

The following configuration snippet almost works:
{code:xml}
  


  



  

  



  

  

...
  

  


  foo
  foo-test
  false



  foo
  foo-prod
  false

  
{code}

Artemis give me an error:
{code}
AMQ222006: Binding already exists with name foo-test, divert will not be 
deployed
{code}

Changing the divert names fixes the problem.

Why can't I use the same name both for the queue and the divert feeding the 
queue?

Since these are different kinds of objects, I should be able to reuse the same 
name, shouldn't I?

  was:
I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
(http://activemq.apache.org/virtual-destinations.html). The use case is a 
single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).

The following configuration snippet almost works:
{code}
  


  



  

  



  

  

...
  

  


  foo
  foo-test
  false



  foo
  foo-prod
  false

  
{code}

Artemis give me an error:
{code}
AMQ222006: Binding already exists with name foo-test, divert will not be 
deployed
{code}

Changing the divert names fixes the problem.

Why can't I use the same name both for the queue and the divert feeding the 
queue?

Since these are different kinds of objects, I should be able to reuse the same 
name, shouldn't I?


> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code:xml}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



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

[jira] [Comment Edited] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Justin Bertram (JIRA)]

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

Justin Bertram edited comment on ARTEMIS-1802 at 4/11/18 2:32 PM:
--

Internally in the broker a _queue_ and _divert_ are actually the same kind of 
thing. They are both "bindings." In other words, both diverts and queues are 
_bound_ to an address; they just do different things with the messages they 
receive. A _queue_ receives a message sent to an address and stores it. A 
_divert_ receives a message sent to an address and diverts it to another 
address.

You might be able to achieve the semantics you're looking for with this 
configuration: 
{code:xml}
  


  


  

...
  
{code}
Using this configuration any message sent to the address "foo" will go into the 
queues "foo-test" and "foo-prod."


was (Author: jbertram):
Internally in the broker a _queue_ and _divert_ are actually the same kind of 
thing. They are both "bindings." In other words, both diverts and queues are 
_bound_ to an address; they just do different things with the messages they 
receive. A _queue_ receives a message sent to an address and stores it. A 
_divert_ receives a message sent to an address and diverts it to another 
address.

You might be able to achieve the semantics you're looking for with this 
configuration: 
{noformat}
  


  


  

...
  
{noformat}
Using this configuration any message sent to the address "foo" will go into the 
queues "foo-test" and "foo-prod."

> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



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

[jira] [Commented] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1802:
-

Internally in the broker a _queue_ and _divert_ are actually the same kind of 
thing. They are both "bindings." In other words, both diverts and queues are 
_bound_ to an address; they just do different things with the messages they 
receive. A _queue_ receives a message sent to an address and stores it. A 
_divert_ receives a message sent to an address and diverts it to another 
address.

You might be able to achieve the semantics you're looking for with this 
configuration: 
{noformat}
  


  


  

...
  
{noformat}
Using this configuration any message sent to the address "foo" will go into the 
queues "foo-test" and "foo-prod."

> Cannot use the same name for a divert and an address
> 
>
> Key: ARTEMIS-1802
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Lionel Cons
>Priority: Major
>
> I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
> (http://activemq.apache.org/virtual-destinations.html). The use case is a 
> single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).
> The following configuration snippet almost works:
> {code}
>   
> 
> 
>   
> 
> 
> 
>   
> 
>   
> 
> 
> 
>   
> 
>   
> 
> ...
>   
>   
> 
> 
>   foo
>   foo-test
>   false
> 
> 
> 
>   foo
>   foo-prod
>   false
> 
>   
> {code}
> Artemis give me an error:
> {code}
> AMQ222006: Binding already exists with name foo-test, divert will not be 
> deployed
> {code}
> Changing the divert names fixes the problem.
> Why can't I use the same name both for the queue and the divert feeding the 
> queue?
> Since these are different kinds of objects, I should be able to reuse the 
> same name, shouldn't I?



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

[jira] [Commented] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1800:
-

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

https://github.com/apache/activemq-artemis/pull/2009#discussion_r180774964
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/QueueControlTest.java
 ---
@@ -2510,6 +2510,39 @@ public void testSendMessage() throws Exception {
   Assert.assertEquals(new String(body), "theBody");
}
 
+   @Test
+   public void testGetScheduledCountOnRemove() throws Exception {
+  long delay = Integer.MAX_VALUE;
+  SimpleString address = RandomUtil.randomSimpleString();
+  SimpleString queue = RandomUtil.randomSimpleString();
+
+  session.createQueue(address, RoutingType.MULTICAST, queue, null, 
durable);
+
+  QueueControl queueControl = createManagementControl(address, queue);
+  Assert.assertEquals(0, queueControl.getScheduledCount());
+
+  Field queueMemorySizeField = 
QueueImpl.class.getDeclaredField("queueMemorySize");
+  queueMemorySizeField.setAccessible(true);
+  final LocalQueueBinding binding = (LocalQueueBinding) 
server.getPostOffice().getBinding(queue);
+  Queue q = binding.getQueue();
+  AtomicInteger queueMemorySize1 = (AtomicInteger) 
queueMemorySizeField.get(q);
+  assertTrue(queueMemorySize1.get() == 0);
+
+  ClientProducer producer = session.createProducer(address);
+  ClientMessage message = session.createMessage(durable);
+  message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
System.currentTimeMillis() + delay);
+  producer.send(message);
+
+  queueControl.removeAllMessages();
+
+  Assert.assertEquals(0, queueControl.getMessageCount());
--- End diff --

I think the removeAllMessages() call is synchronous but if it's an issue 
it's easy enough to switch out the assertion in the test


> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Commented] (ARTEMIS-1800) Incorrect number of messages on queue after remove of scheduled message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1800:
-

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

https://github.com/apache/activemq-artemis/pull/2009#discussion_r180773234
  
--- Diff: 
tests/integration-tests/src/test/java/org/apache/activemq/artemis/tests/integration/management/QueueControlTest.java
 ---
@@ -2510,6 +2510,39 @@ public void testSendMessage() throws Exception {
   Assert.assertEquals(new String(body), "theBody");
}
 
+   @Test
+   public void testGetScheduledCountOnRemove() throws Exception {
+  long delay = Integer.MAX_VALUE;
+  SimpleString address = RandomUtil.randomSimpleString();
+  SimpleString queue = RandomUtil.randomSimpleString();
+
+  session.createQueue(address, RoutingType.MULTICAST, queue, null, 
durable);
+
+  QueueControl queueControl = createManagementControl(address, queue);
+  Assert.assertEquals(0, queueControl.getScheduledCount());
+
+  Field queueMemorySizeField = 
QueueImpl.class.getDeclaredField("queueMemorySize");
+  queueMemorySizeField.setAccessible(true);
+  final LocalQueueBinding binding = (LocalQueueBinding) 
server.getPostOffice().getBinding(queue);
+  Queue q = binding.getQueue();
+  AtomicInteger queueMemorySize1 = (AtomicInteger) 
queueMemorySizeField.get(q);
+  assertTrue(queueMemorySize1.get() == 0);
+
+  ClientProducer producer = session.createProducer(address);
+  ClientMessage message = session.createMessage(durable);
+  message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
System.currentTimeMillis() + delay);
+  producer.send(message);
+
+  queueControl.removeAllMessages();
+
+  Assert.assertEquals(0, queueControl.getMessageCount());
--- End diff --

in a lot of cases, I have had to change this to:

Wait.assertEquals(0, queueuControl::getMessageCount);


Are you sure this is reliable, non asynchronous?


> Incorrect number of messages on queue after remove of scheduled message
> ---
>
> Key: ARTEMIS-1800
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1800
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Justin Bertram
>Assignee: Christopher L. Shannon
>Priority: Major
>
> This will reproduce the failure if added to 
> {{org.apache.activemq.artemis.tests.integration.management.QueueControlTest}}:
> {noformat}
>@Test
>public void testGetScheduledCountOnRemove() throws Exception {
>   long delay = Integer.MAX_VALUE;
>   SimpleString address = RandomUtil.randomSimpleString();
>   SimpleString queue = RandomUtil.randomSimpleString();
>   session.createQueue(address, RoutingType.MULTICAST, queue, null, 
> durable);
>   QueueControl queueControl = createManagementControl(address, queue);
>   Assert.assertEquals(0, queueControl.getScheduledCount());
>   ClientProducer producer = session.createProducer(address);
>   ClientMessage message = session.createMessage(durable);
>   message.putLongProperty(Message.HDR_SCHEDULED_DELIVERY_TIME, 
> System.currentTimeMillis() + delay);
>   producer.send(message);
>   queueControl.removeAllMessages();
>   Assert.assertEquals(0, queueControl.getMessageCount());
>   session.deleteQueue(queue);
>}
> {noformat}



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

[jira] [Commented] (ARTEMIS-1262) JMS 2.0 durable subscription spec violation

[Christopher L. Shannon (JIRA)]

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

Christopher L. Shannon commented on ARTEMIS-1262:
-

I started looking at this more again and about how we can do this.  There are 2 
separate issues here, the first is to make sure the shared and non shared 
durables are separate subscriptions (now they end up as the same which is an 
issue) and the second is to disallow the creation of both in the same namespace.

The first problem can be solved with changing the queue names and then 
naturally the non-shared durable and shared durable subscriptions will be 
separate.  The nice thing about this is it can be done just in the JMS client 
and not break other protocols and a flag can be used to configure the naming 
scheme for the queue for backwards compatibility.

The second issue is more tricky in how to enforce the namespace issue.  As 
Robbie pointed out there will be race condition issues if we try and have the 
client do the check. The other way would be to put the check on the broker side 
(do a check when the binding/queue is created under a lock) but then we run 
into the issue of enforcing this behavior across all protocols which we may or 
may not want to do.  It would also obviously be a breaking change and require a 
major version upgrade.

At the very least I think the the queue name should be changed and do the check 
on the client side even if it isn't perfect.  To me it's a big problem if a 
client creates a non-shared durable subscription and then another client later 
creates a durable subscription with the same clientId/subname and then suddenly 
the broker promotes the original non-shared durable subscription to a shared 
and both clients share the same queue.

> JMS 2.0 durable subscription spec violation
> ---
>
> Key: ARTEMIS-1262
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1262
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.1.0
>Reporter: Christopher L. Shannon
>Priority: Major
>
> There is a JMS 2.0 spec violation with Artemis.  Currently it is possible to 
> first create a durable subscription with a clientId and subscription name and 
> then also create a shared durable subscription using the same clientId and 
> subscription name.  This works because Artemis isn't distinguishing between 
> the two types of consumers during the creation of the consumer.  However, the 
> spec says:
> {quote}A shared durable subscription and an unshared durable subscription may 
> not
> have the same name and client identifier. If the application calls one of the
> createSharedDurableConsumer methods, and an unshared durable 
> subscription already exists with the same name and client identifier, then a
> JMSException or JMSRuntimeException is thrown.{quote}
> I think that there may need to be a flag added somewhere during the creation 
> of the consumer so the broker can tell whether or not the durable 
> subscription is shared vs non-shared so it can reject a shared subscription 
> attempt if a non-shared subscription exists for the same client Id and name.



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

[jira] [Commented] (ARTEMIS-1035) Conversion of MessageID is not working when crossing protocols

[JIRA]

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

Jiri Daněk commented on ARTEMIS-1035:
-

With 2.4.0 broker, when going AMQP -> Core, and maybe in other cases, there is 
a property {{NATIVE_MESSAGE_ID}} added to the received messages which contains 
the original ID.

JMS allows the broker to modify message id (see discussion 
https://stackoverflow.com/questions/29001655/should-the-jmsmessageid-change-between-publish-and-subscribe,
 it is not clear cut, but this is my understanding of their interpretations of 
it). In particular, it supposedly permits id change when sending and receiving 
to/from a topic (the broker creates multiple copies of the original message, 
and the copies can be considered a different message).

Personally, I'd make this ticked an enhancement, asking that the broker does 
not change the id "needlessly". Definition of which is up to discussion.

Portable JMS applications cannot depend on the id being the same anyways, so 
maybe there is no point at all in preserving it, besides saving time needed to 
recompute new id every time...? Sometimes, if something is not required to be 
preserved, it makes sense to take explicit steps to not preserve it every time 
there is opportunity, so that clients do not get used to something that is not 
guaranteed. Like randomized dictionary iteration order in Python, Go and other 
languages.

> Conversion of MessageID is not working when crossing protocols
> --
>
> Key: ARTEMIS-1035
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1035
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, OpenWire
>Affects Versions: 2.0.0
>Reporter: Michal Toth
>Priority: Major
> Fix For: unscheduled
>
>
> Send a message with Openwire client 
> Receive a message with AMQP client.
> Observe message id property being prefixed & suffixed by some binary or hexa 
> data.
> {noformat}
> java  -jar 
> /var/dtests/node_data/clients/java/aoc/target/aoc7-downstream-ga-5.11.0.redhat-630187.jar
>  sender  --log-msgs dict --broker tcp://localhost:61616 --conn-reconnect True 
> --conn-username admin --conn-password admin --address "myQ" --count 2
> {'redelivered': False, 'reply_to': None, 'id': 
> 'mySuperHost-36303-1489414672954-1:1:1:1:1', 'user_id':None, 
> 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 0, 'type': 
> None, 'expiration': 0, 'timestamp': 1489414673301, 'address': 'queue://myQ', 
> 'properties': {}, 'content': None}
> {'redelivered': False, 'reply_to': None, 'id': 
> 'mySuperHost-36303-1489414672954-1:1:1:1:2', 'user_id':None, 
> 'correlation_id': None, 'priority': 4, 'durable': True, 'ttl': 0, 'type': 
> None, 'expiration': 0, 'timestamp': 1489414673324, 'address': 'queue://myQ', 
> 'properties': {}, 'content': None}
> {noformat}
> {noformat}
> /var/dtests/node_data/clients/aac0_receiver  --log-msgs dict --broker 
> admin:admin@localhost:5672 --connection-options "{  sasl_mechanisms : 
> 'PLAIN', protocol : 'amqp1.0' }" --address myQ --count 0
> {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': 
> None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 4, 
> 'durable': True, 'ttl': 0.00e+00, 'size': 25, 'properties': 
> {'JMSXDeliveryCount': None, '_AMQ_DUPL_ID': 
> 'ID:mySuperHost-36303-1489414672954-1:1:1:1:1', '__HDR_ARRIVAL': 0, 
> '__HDR_BROKER_IN_TIME': 1489414673303, '__HDR_COMMAND_ID': 5, 
> '__HDR_DROPPABLE': False, '__HDR_GROUP_SEQUENCE': 0, '__HDR_MESSAGE_ID': 
> '\\x00\\x00\\x00Jn\\x02\\xffae\\x02{\\x00=ID:mySuperHost-36303-1489414672954-1:1\\x00\\x01\\x00\\x01\\x00\\x01',
>  '__HDR_PRODUCER_ID': 
> '\\x00\\x00\\x00F{\\x01+\\x00=ID:mySuperHost-36303-1489414672954-1:1\\x00\\x01\\x00\\x01',
>  'x-amqp-creation-time': 1489414673301, 'x-amqp-delivery-count': 0, 
> 'x-amqp-to': 'myQ', 'x-opt-jms-dest': 0, 'x-opt-jms-msg-type': 0}, 'content': 
> 'Conversion to AMQP error!'}
> {'redelivered': False, 'reply_to': None, 'subject': None, 'content_type': 
> None, 'id': None, 'user_id': None, 'correlation_id': None, 'priority': 4, 
> 'durable': True, 'ttl': 0.00e+00, 'size': 25, 'properties': 
> {'JMSXDeliveryCount': None, '_AMQ_DUPL_ID': 
> 'ID:mySuperHost-36303-1489414672954-1:1:1:1:2', '__HDR_ARRIVAL': 0, 
> '__HDR_BROKER_IN_TIME': 1489414673325, '__HDR_COMMAND_ID': 6, 
> '__HDR_DROPPABLE': False, '__HDR_GROUP_SEQUENCE': 0, '__HDR_MESSAGE_ID': 
> '\\x00\\x00\\x00Jn\\x02\\xffae\\x02{\\x00=ID:mySuperHost-36303-1489414672954-1:1\\x00\\x01\\x00\\x01\\x00\\x02',
>  '__HDR_PRODUCER_ID': 
> '\\x00\\x00\\x00F{\\x01+\\x00=ID:mySuperHost-36303-1489414672954-1:1\\x00\\x01\\x00\\x01',
>  'x-amqp-creation-time': 1489414673324, 'x-amqp-delivery-count': 0, 
> 'x-amqp-to': 'myQ', 

[jira] [Work started] (ARTEMIS-1801) Remove dereferences before null check

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1801 started by Stanislav Knot.
---
> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Resolved] (ARTEMIS-1798) DEBUG message bad write method arg count: public void org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.setUpInactivityParams

[Stanislav Knot (JIRA)]

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

Stanislav Knot resolved ARTEMIS-1798.
-
Resolution: Fixed

> DEBUG message bad write method arg count: public void 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.setUpInactivityParams
> --
>
> Key: ARTEMIS-1798
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1798
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Trivial
>
> {noformat}
> 16:06:31,002 DEBUG 
> [org.apache.activemq.artemis.utils.uri.FluentPropertyBeanIntrospectorWithIgnores]
>  bad write method arg count: public void 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.setUpInactivityParams(org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection,org.apache.activemq.command.WireFormatInfo)
>  throws java.io.IOException: java.beans.IntrospectionException: bad write 
> method arg count: public void 
> org.apache.activemq.artemis.core.protocol.openwire.OpenWireProtocolManager.setUpInactivityParams(org.apache.activemq.artemis.core.protocol.openwire.OpenWireConnection,org.
> {noformat}
> setUpInactivityParams does not set any property, which causes this error 
> message when debug logging is enabled.



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

[jira] [Work started] (ARTEMIS-1782) Missing drop-down menu with create/delete/browse buttons in hawtio console

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1782 started by Stanislav Knot.
---
> Missing drop-down menu with create/delete/browse buttons in hawtio console
> --
>
> Key: ARTEMIS-1782
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1782
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> When hawtio console is opened, there is drop-down menu, that usually contains 
> 'create' 'delete' or 'browse' buttons, missing. Even though refreshing the 
> page helps, it is not obvious that it will solve the issue. It causes 
> confusion and is annoying to users.



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

[jira] [Work started] (ARTEMIS-1744) Address or queue containing '*' or '?' cannot be deleted from hawtio console

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1744 started by Stanislav Knot.
---
> Address or queue containing '*' or '?' cannot be deleted from hawtio console
> 
>
> Key: ARTEMIS-1744
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1744
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>




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

[jira] [Work started] (ARTEMIS-1787) Openwire message should not contain internal property

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1787 started by Stanislav Knot.
---
> Openwire message should not contain internal property
> -
>
> Key: ARTEMIS-1787
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1787
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Major
>
> Openwire message contains __AMQ_CID property.



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

[jira] [Created] (ARTEMIS-1802) Cannot use the same name for a divert and an address

[Lionel Cons (JIRA)]

Lionel Cons created ARTEMIS-1802:


 Summary: Cannot use the same name for a divert and an address
 Key: ARTEMIS-1802
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1802
 Project: ActiveMQ Artemis
  Issue Type: Bug
Affects Versions: 2.5.0
Reporter: Lionel Cons


I'm trying to use diverts to emulate ActiveMQ 5's virtual destinations 
(http://activemq.apache.org/virtual-destinations.html). The use case is a 
single topic ({{foo}}) bound to two queues ({{foo-test}} and {{foo-prod}}).

The following configuration snippet almost works:
{code}
  


  



  

  



  

  

...
  

  


  foo
  foo-test
  false



  foo
  foo-prod
  false

  
{code}

Artemis give me an error:
{code}
AMQ222006: Binding already exists with name foo-test, divert will not be 
deployed
{code}

Changing the divert names fixes the problem.

Why can't I use the same name both for the queue and the divert feeding the 
queue?

Since these are different kinds of objects, I should be able to reuse the same 
name, shouldn't I?



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180654379
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2769,7 +2769,7 @@ public Queue createQueue(final AddressInfo addrInfo,
  throw 
ActiveMQMessageBundle.BUNDLE.invalidRoutingTypeForAddress(rt, 
info.getName().toString(), info.getRoutingTypes());
   }
 
-  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
+  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo
 == null ? RoutingType.ANYCAST 
:addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
--- End diff --

@jdanekrh Good catch!


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180652792
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2769,7 +2769,7 @@ public Queue createQueue(final AddressInfo addrInfo,
  throw 
ActiveMQMessageBundle.BUNDLE.invalidRoutingTypeForAddress(rt, 
info.getName().toString(), info.getRoutingTypes());
   }
 
-  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
+  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo
 == null ? RoutingType.ANYCAST 
:addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
--- End diff --

About 20 lines above this one is

RoutingType rt = (routingType == null ? 
ActiveMQDefaultConfiguration.getDefaultRoutingType() : routingType);


[here](https://github.com/apache/activemq-artemis/blob/fa3e37fdb91c285bcfe87cab3d771dfe80019e18/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java#L2754)
 and 
[here](https://github.com/apache/activemq-artemis/blob/fa3e37fdb91c285bcfe87cab3d771dfe80019e18/artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java#L2865)

So maybe that one?


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1740) Add support for regex based certificate authentication

[Lionel Cons (JIRA)]

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

Lionel Cons commented on ARTEMIS-1740:
--

I've submitted a pull request to add this feature. If this is accepted then I 
will update the documentation accordingly.

> Add support for regex based certificate authentication
> --
>
> Key: ARTEMIS-1740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Priority: Major
>
> The current certificate authentication module 
> ({{TextFileCertificateLoginModule}}) uses a file mapping user names to DNs.
> In some cases, the list of known DNs can be large and dynamic. This is the 
> case for instance when using host certificates.
> Host certificates could be very dynamic (when new virtual machines get 
> created) while keeping a fixed structure such as {{CN=hostxyz.acme.org, 
> OU=computers, DC=acme, DC=org}}. It is impractical to generate all the 
> possible DNs and feed this to Artemis.
> It would be very useful to have regular expression based certificate 
> authentication. With the example above, we could have a single line:
> {quote}
> acme.computers=/^CN=\w+\.acme\.org, OU=computers, DC=acme, DC=org$/
> {quote}



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

[jira] [Commented] (ARTEMIS-1740) Add support for regex based certificate authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1740:
-

GitHub user LionelCons opened a pull request:

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

ARTEMIS-1740: Add support for regex based certificate authentication

This adds the possibility to have an optional properties file containing 
regular expressions to match against the DN.

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

$ git pull https://github.com/LionelCons/activemq-artemis artemis_1740

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

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


commit e8fc4975f5a758ee7204f89d1649cc326bcd5085
Author: Lionel Cons 
Date:   2018-04-11T06:59:24Z

ARTEMIS-1740: Add support for regex based certificate authentication




> Add support for regex based certificate authentication
> --
>
> Key: ARTEMIS-1740
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1740
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Reporter: Lionel Cons
>Priority: Major
>
> The current certificate authentication module 
> ({{TextFileCertificateLoginModule}}) uses a file mapping user names to DNs.
> In some cases, the list of known DNs can be large and dynamic. This is the 
> case for instance when using host certificates.
> Host certificates could be very dynamic (when new virtual machines get 
> created) while keeping a fixed structure such as {{CN=hostxyz.acme.org, 
> OU=computers, DC=acme, DC=org}}. It is impractical to generate all the 
> possible DNs and feed this to Artemis.
> It would be very useful to have regular expression based certificate 
> authentication. With the example above, we could have a single line:
> {quote}
> acme.computers=/^CN=\w+\.acme\.org, OU=computers, DC=acme, DC=org$/
> {quote}



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

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

https://github.com/apache/activemq-artemis/pull/2010#discussion_r180649567
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/ActiveMQServerImpl.java
 ---
@@ -2769,7 +2769,7 @@ public Queue createQueue(final AddressInfo addrInfo,
  throw 
ActiveMQMessageBundle.BUNDLE.invalidRoutingTypeForAddress(rt, 
info.getName().toString(), info.getRoutingTypes());
   }
 
-  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
+  final QueueConfig queueConfig = 
queueConfigBuilder.filter(filter).pagingManager(pagingManager).user(user).durable(durable).temporary(temporary).autoCreated(autoCreated).routingType(addrInfo
 == null ? RoutingType.ANYCAST 
:addrInfo.getRoutingType()).maxConsumers(maxConsumers).purgeOnNoConsumers(purgeOnNoConsumers).exclusive(exclusive).lastValue(lastValue).build();
--- End diff --

What should be default routing type?


> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Commented] (ARTEMIS-1801) Remove dereferences before null check

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1801:
-

GitHub user stanlyDoge opened a pull request:

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

ARTEMIS-1801 removing null-unchecked dereferences

There were some cases where value was checked for null and later directly 
dereferenced without check. I added checks. I am not sure about "default 
behaviour" tho. Can anybody check?

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

$ git pull https://github.com/stanlyDoge/activemq-artemis ARTEMIS-1801

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

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


commit 8f393828473c75321b28a4fe63f5f08fb7006bbe
Author: Stanislav Knot 
Date:   2018-04-11T06:43:07Z

ARTEMIS-1801 removing null-unchecked dereferences




> Remove dereferences before null check
> -
>
> Key: ARTEMIS-1801
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> There are some dereferences before object is checked for null.



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

[jira] [Created] (ARTEMIS-1801) Remove dereferences before null check

[Stanislav Knot (JIRA)]

Stanislav Knot created ARTEMIS-1801:
---

 Summary: Remove dereferences before null check
 Key: ARTEMIS-1801
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1801
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Stanislav Knot
Assignee: Stanislav Knot


There are some dereferences before object is checked for null.



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