[jira] [Commented] (ARTEMIS-4212) Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

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

Commit 74fa4ca7580f1fce3f2727dab5edce41cc68af92 in activemq-artemis's branch refs/heads/main from Justin Bertram
[ https://gitbox.apache.org/repos/asf?p=activemq-artemis.git;h=74fa4ca758 ]

ARTEMIS-4212 fix sending msgs to address w/mismatching routing types

When sending, for example, to a predefined anycast address and queue
from a multicast (JMS topic) producer, the routed count on the address
is incremented, but the message count on the matching queue is not. No
indication is given at the client end that the messages failed to get
routed - the messages are just silently dropped.

Fixing this problem requires a slight semantic change. The broker is now
more strict in what it allows specifically with regards to
auto-creation. If, for example, a JMS application attempts to send a
message to a topic and the corresponding multicast address doesn't exist
already or the broker cannot automatically create it or update it then
sending the message will fail.

Also, part of this commit moves a chunk of auto-create logic into
ServerSession and adds an enum for auto-create results. Aside from
helping fix this specific issue this can serve as a foundation for
de-duplicating the auto-create logic spread across many of the protocol
implementations.


> Unexpected Behavior when Routing Type of Destinations Doesn't Match Clients
> ---------------------------------------------------------------------------
>
>                 Key: ARTEMIS-4212
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4212
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Justin Bertram
>            Assignee: Justin Bertram
>            Priority: Major
>          Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> When the routing type of an address (and associated queue) does not match the routing type of a client producer, the resultant behavior is a bit unexpected.
> Expected Behavior:
> If a client sends a message to an address / queue with the same name, but a different routing type, the expected behavior would be to throw some sort of InvalidDestinationException (if auto-create is not enabled), or to create the matching address and queue with the appropriate routing type. The routing count on the existing address (with non-matching routing type) should remain unchanged.
> Actual Behavior:
> When sending, for example, to a predefined anycast address and queue from a multiccast (Topic) producer, the routed count on the address is incremented, but the message count on the matching queue is not. No indication is given at the client end that the messages failed to get routed - they are silently dropped.
> This is reproducible using a qpid / proton queue producer to send to a multicast address or using a topic producer to send to an anycast address, e.g.:
> 1. Create a a broker, setting auto-create-queues and auto-create addresses to "false" for the catch-all address-setting
> 2. Start the broker and create a an address and matching queue with a ANYCAST routing type
> 3. Send 1000 messages to the broker using the same queue name but mismatched routing type:
> {code}
> ./artemis producer --url amqp://localhost:61616 --user admin --password admin --destination topic://{QUEUE NAME} --protocol amqp
> {code}
> No error is emitted and the routing count is incremented by 1000 at the address level, but remains unchanged at the destination level.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)