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

Erwin Dondorp updated ARTEMIS-4132:
-----------------------------------
    Description: 
using:
* broker configured with default-address-routing-type=MULTICAST (and 
default-queue-routing-type=MULTICAST)
* clients built with python-qpid-proton

When a client is publishing to a new address, the address is created with 
routing type MULTICAST. this is ok.
When a client is subscribing to a new address, the address is created with 
routing type ANYCAST, which is unexpected.

To repeat:
* create plain broker using {{bin/artemis create --allow-anonymous --user admin 
--password admin broker1}}
* (optional) adjust {{broker1/etc/bootstrap.xml}} and/or adjust 
{{broker1/etc/jolokia-access.xml}} when the broker console can otherwise not be 
used/reached.
* update {{broker.xml}}: add these 2 lines to the {{address-settings}} for 
'{{#}}'
{{<default-queue-routing-type>MULTICAST</default-queue-routing-type>}}
{{<default-address-routing-type>MULTICAST</default-address-routing-type>}}
* start broker with {{broker1/bin/artemis run}}
* adjust the broker address in the 2 python files
* use supplied docker files to build and run a sender and/or a receiver

scenario 1:
run only the broker and the sender
see address '{{demoaddress}}' appear as multicast address
any messages will disappear as expected because there is no consumer

scenario 2:
run only the broker and the receiver
see address '{{demoaddress}}' appear as anycast (unexpected) address
a queue with the same name is created under it (consistent)

remove the address '{{demoaddress}}' between runs because the effect only 
appears for new addresses

see the attached files

[~jbertram]: as discussed in the mailing list

  was:
using:
* broker configured with default-address-routing-type=MULTICAST (and 
default-queue-routing-type=MULTICAST)
* clients built with python-qpid-proton

When a client is publishing to a new address, the address is created with 
routing type MULTICAST. this is ok.
When a client is subscribing to a new address, the address is created with 
routing type ANYCAST, which is unexpected.

To repeat:
* create plain broker using {{bin/artemis create --allow-anonymous --user admin 
--password admin broker1}}
* (optional) adjust {{broker1/etc/bootstrap.xml}} and/or adjust 
{{broker1/etc/jolokia-access.xml}} when the broker console can otherwise not be 
used/reached.
* update {{broker.xml}}: add these 2 lines to the {{address-settings}} for 
'{{#}}'
{{<default-queue-routing-type>MULTICAST</default-queue-routing-type>}}
{{<default-address-routing-type>MULTICAST</default-address-routing-type>}}
* start broker with {{broker1/bin/artemis run}}
* adjust the broker address in the 2 python files
* use supplied docker files to build and run a sender and/or a receiver

scenario 1:
run only the broker and the sender
see address '{{demoaddress}}' appear as multicast address
any messages will disappear as expected because there is no consumer

scenario 2:
run only the broker and the receiver
see address '{{demoaddress}}' appear as anycast (unexpected) address
a queue with the same name is created under it (consistent)

remove the address '{{demoaddress}}' between runs because the effect only 
appears for new addresses

see the attached files


> broker uses anycast for amqp destination which is configured as multicast
> -------------------------------------------------------------------------
>
>                 Key: ARTEMIS-4132
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-4132
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: AMQP
>    Affects Versions: 2.27.1
>            Reporter: Erwin Dondorp
>            Priority: Major
>         Attachments: Dockerfile.recv, Dockerfile.send, recv.py, send.py
>
>
> using:
> * broker configured with default-address-routing-type=MULTICAST (and 
> default-queue-routing-type=MULTICAST)
> * clients built with python-qpid-proton
> When a client is publishing to a new address, the address is created with 
> routing type MULTICAST. this is ok.
> When a client is subscribing to a new address, the address is created with 
> routing type ANYCAST, which is unexpected.
> To repeat:
> * create plain broker using {{bin/artemis create --allow-anonymous --user 
> admin --password admin broker1}}
> * (optional) adjust {{broker1/etc/bootstrap.xml}} and/or adjust 
> {{broker1/etc/jolokia-access.xml}} when the broker console can otherwise not 
> be used/reached.
> * update {{broker.xml}}: add these 2 lines to the {{address-settings}} for 
> '{{#}}'
> {{<default-queue-routing-type>MULTICAST</default-queue-routing-type>}}
> {{<default-address-routing-type>MULTICAST</default-address-routing-type>}}
> * start broker with {{broker1/bin/artemis run}}
> * adjust the broker address in the 2 python files
> * use supplied docker files to build and run a sender and/or a receiver
> scenario 1:
> run only the broker and the sender
> see address '{{demoaddress}}' appear as multicast address
> any messages will disappear as expected because there is no consumer
> scenario 2:
> run only the broker and the receiver
> see address '{{demoaddress}}' appear as anycast (unexpected) address
> a queue with the same name is created under it (consistent)
> remove the address '{{demoaddress}}' between runs because the effect only 
> appears for new addresses
> see the attached files
> [~jbertram]: as discussed in the mailing list



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

Reply via email to