[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=16437554#comment-16437554
 ] 

Justin Bertram commented on ARTEMIS-1794:
-

In your use-case how are the clients of /topic/foo and /queue/foo related?  Are 
messages sent to /topic/foo being consumed from /queue/foo?

> 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

[Justin Bertram (JIRA)]

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

Justin Bertram commented on ARTEMIS-1802:
-

bq. 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?

I think that's reasonable.

However, this may be moot for your use-case if we can work out ARTEMIS-1794.

> 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] (ARTEMIS-1805) Some broker operations in hawtio causes error

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1805:
-

GitHub user stanlyDoge opened a pull request:

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

ARTEMIS-1805 fix for broker operations in hawtio

There are two operations, which causes an error while selected in hawtio 
console under broker/operations. Adding @Operation annotation to these methods 
fixes an error, but methods are exposed and I am not 100% sure that is correct. 
I also unified capitalized first letter of methods description.

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

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

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

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


commit 59f91f4c2e79777e40e5b220c0fad8faf63437e5
Author: Stanislav Knot 
Date:   2018-04-13T09:20:20Z

ARTEMIS-1805 fix for broker operations in hawtio




> Some broker operations in hawtio causes error
> -
>
> Key: ARTEMIS-1805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> sendQueueInfoToQueue and updateDuplicateIdCache operations cause an error if 
> selected in hawtio console. Adding @Operation annotation fixes error, but 
> methods are exposed and I am not 100% sure it is correct.



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

[jira] [Updated] (ARTEMIS-1805) Some broker operations in hawtio causes error

[Stanislav Knot (JIRA)]

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

Stanislav Knot updated ARTEMIS-1805:

Description: updateQueue, sendQueueInfoToQueue and updateDuplicateIdCache 
operations cause an error if selected in hawtio console. Adding @Operation 
annotation fixes error, but methods are exposed and I am not 100% sure it is 
correct.  (was: sendQueueInfoToQueue and updateDuplicateIdCache operations 
cause an error if selected in hawtio console. Adding @Operation annotation 
fixes error, but methods are exposed and I am not 100% sure it is correct.)

> Some broker operations in hawtio causes error
> -
>
> Key: ARTEMIS-1805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> updateQueue, sendQueueInfoToQueue and updateDuplicateIdCache operations cause 
> an error if selected in hawtio console. Adding @Operation annotation fixes 
> error, but methods are exposed and I am not 100% sure it is correct.



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

[jira] [Created] (ARTEMIS-1805) Some broker operations in hawtio causes error

[Stanislav Knot (JIRA)]

Stanislav Knot created ARTEMIS-1805:
---

 Summary: Some broker operations in hawtio causes error
 Key: ARTEMIS-1805
 URL: https://issues.apache.org/jira/browse/ARTEMIS-1805
 Project: ActiveMQ Artemis
  Issue Type: Bug
Reporter: Stanislav Knot
Assignee: Stanislav Knot


sendQueueInfoToQueue and updateDuplicateIdCache operations cause an error if 
selected in hawtio console. Adding @Operation annotation fixes error, but 
methods are exposed and I am not 100% sure it is correct.



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

[jira] [Work started] (ARTEMIS-1805) Some broker operations in hawtio causes error

[Stanislav Knot (JIRA)]

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

Work on ARTEMIS-1805 started by Stanislav Knot.
---
> Some broker operations in hawtio causes error
> -
>
> Key: ARTEMIS-1805
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1805
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>Reporter: Stanislav Knot
>Assignee: Stanislav Knot
>Priority: Minor
>
> sendQueueInfoToQueue and updateDuplicateIdCache operations cause an error if 
> selected in hawtio console. Adding @Operation annotation fixes error, but 
> methods are exposed and I am not 100% sure it is correct.



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

[jira] [Commented] (ARTEMIS-1803) Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1803:
-

Github user michaelandrepearce commented on the issue:

https://github.com/apache/activemq-artemis/pull/2012
  
@franz1981, any comment?


> Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks
> --
>
> Key: ARTEMIS-1803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1803
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
>
> Right now a MessageReference will track a consumerId (in certain scenarios) 
> but the sessionId is not included.  This is a problem because consumerIds are 
> not unique and are duplicated across sessions.  In order to find a unique 
> consumer you need the sessionId and consumerId as well.   This is a problem 
> for plugins implementing messageExpired and messageAcknowledged as they can't 
> get the exact consumer based on just the consumerId.
> To solve this the ServerConsumer object responsible for acknowledging the 
> message or expiring the message should be passed to those callback methods.  
> If consumer doesn't apply (such as when the broker expires internally or 
> internally moves messages and acks) then the consumer object will be 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=16437293#comment-16437293
 ] 

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_r181386656
  
--- Diff: 
artemis-server/src/main/java/org/apache/activemq/artemis/core/server/impl/QueueImpl.java
 ---
@@ -2712,6 +2713,11 @@ 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) {
+ ActiveMQServerLogger.LOGGER.nullRefMessage();
+ throw new ActiveMQNullRefException("Reference to message is 
null");
--- End diff --

Was this an accident? WEren't you supposed to use NULL_REF.createException 
here?


> 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-1803) Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1803:
-

Github user franz1981 commented on the issue:

https://github.com/apache/activemq-artemis/pull/2012
  
@michaelandrepearce @cshannon my sider-sense doesn't feel dangers anymore :


> Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks
> --
>
> Key: ARTEMIS-1803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1803
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
>
> Right now a MessageReference will track a consumerId (in certain scenarios) 
> but the sessionId is not included.  This is a problem because consumerIds are 
> not unique and are duplicated across sessions.  In order to find a unique 
> consumer you need the sessionId and consumerId as well.   This is a problem 
> for plugins implementing messageExpired and messageAcknowledged as they can't 
> get the exact consumer based on just the consumerId.
> To solve this the ServerConsumer object responsible for acknowledging the 
> message or expiring the message should be passed to those callback methods.  
> If consumer doesn't apply (such as when the broker expires internally or 
> internally moves messages and acks) then the consumer object will be null.



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

[jira] [Commented] (ARTEMIS-1803) Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on ARTEMIS-1803:
-

Github user cshannon commented on the issue:

https://github.com/apache/activemq-artemis/pull/2012
  
@franz1981  and @michaelandrepearce  - thanks for taking a look


> Pass ServerConsumer to messageExpired and messageAcknowledged plugin callbacks
> --
>
> Key: ARTEMIS-1803
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1803
> Project: ActiveMQ Artemis
>  Issue Type: Improvement
>Affects Versions: 2.5.0
>Reporter: Christopher L. Shannon
>Assignee: Christopher L. Shannon
>Priority: Minor
>
> Right now a MessageReference will track a consumerId (in certain scenarios) 
> but the sessionId is not included.  This is a problem because consumerIds are 
> not unique and are duplicated across sessions.  In order to find a unique 
> consumer you need the sessionId and consumerId as well.   This is a problem 
> for plugins implementing messageExpired and messageAcknowledged as they can't 
> get the exact consumer based on just the consumerId.
> To solve this the ServerConsumer object responsible for acknowledging the 
> message or expiring the message should be passed to those callback methods.  
> If consumer doesn't apply (such as when the broker expires internally or 
> internally moves messages and acks) then the consumer object will be null.



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