[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664714#comment-16664714
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
Disagree AMQP is just a protocol. A broker is just another client. There is
nothing to say an address cannot be both anycast and multicast.
And as such if you have left the setting to allow dynamic creation on the
broker then youre allowing if the type is not currently on the address for that
to be created is valid.
If you dont want that simply disable the ability to create queues
dynamically broker side
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2113) When AMQP links are opened and closed in quick succession, Artemis doesn’t always respond with attach/detach frames confirming the opening/closing of the links
[
https://issues.apache.org/jira/browse/ARTEMIS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664651#comment-16664651
]
Simon Chalmers commented on ARTEMIS-2113:
-
ArtemisTest.zip tester app attached.
The tester .net app requires to run / setup:
• Linux virtual machine.
• This requires the dotnet-sdk-2.1. I followed these instructions
https://www.microsoft.com/net/download/linux-package-manager/debian9/sdk-current
to get it installed.
Once you’ve done that, to run the tester, unzip it and run: dotnet
ArtemisTest.dll
It takes the following parameters:
• -h for host
• -u for username
• -p for password
For example: dotnet ArtemisTest.dll -h 172.31.19.185 -u admin -p Password11
I get the same error/results against 2.6.3 (attached as artemis-2.6.3.log and
dotnet-artemis-2.6.3) and against this fork/branch:
https://github.com/clebertsuconic/activemq-artemis/tree/AMQP-final (attached as
artemis-2.7.log and dotnet-artemis-2.7.0)
> When AMQP links are opened and closed in quick succession, Artemis doesn’t
> always respond with attach/detach frames confirming the opening/closing of
> the links
> ---
>
> Key: ARTEMIS-2113
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2113
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.3
> Environment: This test was done in .NET using the Amqp.Net Lite
> library 2.1.4 (which is the latest version).
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: ArtemisTest.zip, artemis-2.6.3.log, artemis-2.7.0.log,
> dotnet-artemis-2.6.3.txt, dotnet-artemis-2.7.0.txt
>
>
> A trace of a message exchange with Artemis where this has occurred is below.
> The lines highlighted in yellow show opening and then closing two AMQP links,
> but Artemis doesn’t respond after that with its own attach/detach frames,
> which acknowledge the opening/closing of those links. The lines highlighted
> in green are heartbeat frames sent to Artemis, sent every 15 seconds, which
> illustrates that one minute passed without receiving the attach/detach frames
> from Artemis.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-43a6c9ad,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#14892c}SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty{color}
> Note that this doesn’t always happen. Sometimes Artemis does respond, as
> shown by the lines highlighted in bold/grey in the trace below.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-b00e0be7,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(
[jira] [Updated] (ARTEMIS-2113) When AMQP links are opened and closed in quick succession, Artemis doesn’t always respond with attach/detach frames confirming the opening/closing of the links
[
https://issues.apache.org/jira/browse/ARTEMIS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Chalmers updated ARTEMIS-2113:
Attachment: ArtemisTest.zip
> When AMQP links are opened and closed in quick succession, Artemis doesn’t
> always respond with attach/detach frames confirming the opening/closing of
> the links
> ---
>
> Key: ARTEMIS-2113
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2113
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.3
> Environment: This test was done in .NET using the Amqp.Net Lite
> library 2.1.4 (which is the latest version).
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: ArtemisTest.zip, artemis-2.6.3.log, artemis-2.7.0.log,
> dotnet-artemis-2.6.3.txt, dotnet-artemis-2.7.0.txt
>
>
> A trace of a message exchange with Artemis where this has occurred is below.
> The lines highlighted in yellow show opening and then closing two AMQP links,
> but Artemis doesn’t respond after that with its own attach/detach frames,
> which acknowledge the opening/closing of those links. The lines highlighted
> in green are heartbeat frames sent to Artemis, sent every 15 seconds, which
> illustrates that one minute passed without receiving the attach/detach frames
> from Artemis.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-43a6c9ad,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#14892c}SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty{color}
> Note that this doesn’t always happen. Sometimes Artemis does respond, as
> shown by the lines highlighted in bold/grey in the trace below.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-b00e0be7,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> *{color:#707070}RECV (ch=0)
> attach(name:link1,handle:0,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:q1)){color}*
> RECV (ch=0)
> flow(next-in-id:4294967293,in-window:2147483647,next-out-id:1,out-window:2147483647,handle:0,delivery-count:0,link-credit:1000)
> *{color:#707070}RECV (ch=0) detach(handle:0,closed:True){color}*
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True){color}
> {color:#14892c}SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty{color}
--
This message was sent by A
[jira] [Commented] (ARTEMIS-2123) Paging not stopped if there are no messages on one subscription
[ https://issues.apache.org/jira/browse/ARTEMIS-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664643#comment-16664643 ] ASF GitHub Bot commented on ARTEMIS-2123: - Github user wy96f commented on the issue: https://github.com/apache/activemq-artemis/pull/2369 > @wy96f are you waiting a release to apply your patch? @clebertsuconic We have an internal branch. We will upgrade our cluster after a month. > Paging not stopped if there are no messages on one subscription > --- > > Key: ARTEMIS-2123 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2123 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: yangwei >Priority: Major > > Reproduction steps: > # create a topic t and two subscriptions ta, tb > # send messages to ta and tb > # create ta consumers and receive all messages from ta > # close consumers > # only send message to tb > # create tb consumers and receive all message from tb > # topic not stopped paging -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2113) When AMQP links are opened and closed in quick succession, Artemis doesn’t always respond with attach/detach frames confirming the opening/closing of the links
[
https://issues.apache.org/jira/browse/ARTEMIS-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Chalmers updated ARTEMIS-2113:
Attachment: artemis-2.6.3.log
artemis-2.7.0.log
dotnet-artemis-2.7.0.txt
dotnet-artemis-2.6.3.txt
> When AMQP links are opened and closed in quick succession, Artemis doesn’t
> always respond with attach/detach frames confirming the opening/closing of
> the links
> ---
>
> Key: ARTEMIS-2113
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2113
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.3
> Environment: This test was done in .NET using the Amqp.Net Lite
> library 2.1.4 (which is the latest version).
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: artemis-2.6.3.log, artemis-2.7.0.log,
> dotnet-artemis-2.6.3.txt, dotnet-artemis-2.7.0.txt
>
>
> A trace of a message exchange with Artemis where this has occurred is below.
> The lines highlighted in yellow show opening and then closing two AMQP links,
> but Artemis doesn’t respond after that with its own attach/detach frames,
> which acknowledge the opening/closing of those links. The lines highlighted
> in green are heartbeat frames sent to Artemis, sent every 15 seconds, which
> illustrates that one minute passed without receiving the attach/detach frames
> from Artemis.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-43a6c9ad,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#14892c}SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty
> SEND (ch=0) empty{color}
> Note that this doesn’t always happen. Sometimes Artemis does respond, as
> shown by the lines highlighted in bold/grey in the trace below.
> SEND AMQP 3 1 0 0
> RECV sasl-mechanisms(sasl-server-mechanisms:[PLAIN,ANONYMOUS])
> SEND sasl-init(mechanism:PLAIN,initial-response:...,hostname:localhost)
> RECV sasl-outcome(code:0)
> SEND AMQP 0 1.0.0
> SEND (ch=0)
> open(container-id:AMQPNetLite-b00e0be7,host-name:localhost,max-frame-size:262144,channel-max:255,idle-time-out:2147483647)
> RECV AMQP 0 1 0 0
> RECV (ch=0)
> open(container-id:0.0.0.0,max-frame-size:131072,channel-max:65535,idle-time-out:3,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY,SHARED-SUBS,ANONYMOUS-RELAY],properties:[product:apache-activemq-artemis,version:2.6.3])
> SEND (ch=0)
> begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:63)
> RECV (ch=0)
> begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True)
> SEND (ch=0)
> attach(name:link0,handle:1,role:False,source:source(),target:target(address:q0),initial-delivery-count:0)
> SEND (ch=0) detach(handle:1,closed:True){color}
> *{color:#707070}RECV (ch=0)
> attach(name:link1,handle:0,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:q1)){color}*
> RECV (ch=0)
> flow(next-in-id:4294967293,in-window:2147483647,next-out-id:1,out-window:2147483647,handle:0,delivery-count:0,link-credit:1000)
> *{color:#707070}RECV (ch=0) detach(handle:0,closed:True){color}*
> {color:#f6c342}SEND (ch=0)
> attach(name:link1,handle:0,role:False,source:source(),target:target(address:q1),initial-delivery-count:0)
> SEND (ch=0) detach(handle:0,closed:True){color}
> {color:#14892c}SEND (ch=0) empt
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664488#comment-16664488 ] ASF subversion and git services commented on ARTEMIS-2149: -- Commit 5bd533a97444abffe78572f00f9d8c8d02ed5e56 in activemq-artemis's branch refs/heads/2.6.x from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=5bd533a ] ARTEMIS-2149 Protecting message.sendBuffer from races encoding it (cherry picked from commit 775e7d26039394978aa8dcd6729e27565f35b121) > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664487#comment-16664487 ] ASF GitHub Bot commented on ARTEMIS-2149: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2396 > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664486#comment-16664486 ] ASF subversion and git services commented on ARTEMIS-2149: -- Commit 775e7d26039394978aa8dcd6729e27565f35b121 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=775e7d2 ] ARTEMIS-2149 Protecting message.sendBuffer from races encoding it > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664485#comment-16664485 ] ASF GitHub Bot commented on ARTEMIS-2149: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 @michaelandrepearce I will merge this now.. but if you could still review it after I merged it? we can send further commits. > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664476#comment-16664476 ] ASF GitHub Bot commented on ARTEMIS-2149: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 This is now ready to be merged.. (I had a word WIP on the name here before); > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-6864) Add appropriate Java 9 JVM arguments to allow reflective access to sun.* classes
[ https://issues.apache.org/jira/browse/AMQ-6864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664462#comment-16664462 ] Jeff Gullett commented on AMQ-6864: --- Java 9 and 10 are already EOL, so this issue should be closed to AMQ-7087. > Add appropriate Java 9 JVM arguments to allow reflective access to sun.* > classes > > > Key: AMQ-6864 > URL: https://issues.apache.org/jira/browse/AMQ-6864 > Project: ActiveMQ > Issue Type: Bug >Reporter: Tim Bain >Priority: Major > > As reported on the user mailing list > (http://activemq.2283324.n4.nabble.com/exception-while-launching-my-application-with-JRE9-when-it-tries-to-establish-a-secure-socket-connecq-td4732904.html), > when ActiveMQ runs on a Java 9 JRE, it encounters security exceptions. > The Java 9 JRE intentionally prevents access to non-public classes > (especially the sun.* ones), which apparently includes reflective access to > classes that implement (and are referred to by) public interfaces in java.* > and javax.*. There are several JVM arguments that appear to allow that > access; --add-exports seems to be the one best-suited to our needs based on > about 10 minutes of research, but a more thorough examination of the > available options (including --add-opens) should be done before settling on > the approach to use. Alternatively, there may be some Java 9-compliant way to > do reflection without hitting this issue, or maybe in some cases we can > eliminate the use of reflection in favor of compiled code. > This will probably be a game of Whack-A-Mole as different users stumble > across different places where we use reflection but haven't yet added a JVM > flag, but hopefully we can knock off most of the instances on the first try > and only have a few places where we need to take another swing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7087) Add Java 11 Support
Jeff Gullett created AMQ-7087: - Summary: Add Java 11 Support Key: AMQ-7087 URL: https://issues.apache.org/jira/browse/AMQ-7087 Project: ActiveMQ Issue Type: Improvement Components: Broker Affects Versions: 5.15.6 Environment: Windows 10 with the OpenJDK 11 "bin" directory on the path. Reporter: Jeff Gullett Java 8 support is ending in January, 2019 (in 2 months). Currently, the ActiveMQ Broker only supports Java 8. When I try to start the broker using Java 11 (the latest long-term-support version), I get the following error: Unable to execute Java command. The system cannot find the file specified. (0x2) Critical error: wait for JVM process failed Since both Java 9 and Java 10 are already EOL, support for Java 11 needs to be added by January 2019. The issue to add Java 9 support (AMQ-6864) is OBE, and should be replaced by this issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664455#comment-16664455 ] ASF GitHub Bot commented on ARTEMIS-2149: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2396 ARTEMIS-2149 Protecting message.sendBuffer from races encoding it You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2149 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2396.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 #2396 commit 2823cdf7e222faf4dacdc9274febb1fba3ede45c Author: Clebert Suconic Date: 2018-10-25T21:27:47Z ARTEMIS-2149 Protecting message.sendBuffer from races encoding it > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
[ https://issues.apache.org/jira/browse/ARTEMIS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664456#comment-16664456 ] ASF GitHub Bot commented on ARTEMIS-2149: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2396 @michaelandrepearce can you review this one please. > CoreMessage may have issues encoding if messageChanged is called for any > reason. > > > Key: ARTEMIS-2149 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > If the message body Valid is changed for any reason, and you have the message > being sent for multiple consumers you will get IIOB or other encoding / > decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2149) CoreMessage may have issues encoding if messageChanged is called for any reason.
clebert suconic created ARTEMIS-2149: Summary: CoreMessage may have issues encoding if messageChanged is called for any reason. Key: ARTEMIS-2149 URL: https://issues.apache.org/jira/browse/ARTEMIS-2149 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP, Broker Affects Versions: 2.6.3 Reporter: clebert suconic Assignee: clebert suconic Fix For: 2.7.0, 2.6.4 If the message body Valid is changed for any reason, and you have the message being sent for multiple consumers you will get IIOB or other encoding / decoding issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664237#comment-16664237
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce re: "if producer explicitly sets a routing type, it
must be honoured", I'm not sure what you mean there.
At least from AMQP, the routing types is a property of the address, not the
sender. That is it affects the behaviour of that address for all clients using
it.
Let's say I create an address with --no-anycast and --multicast, bind a
named durable subscription queue to it, create a receiver on that named
subscription queue, and two further receivers. If I know create a sender and
request the 'queue' capability' (or don't request any capability), the
definition of the address is changed and a queue with the same name as the
address is created. However the messages from that sender are still enqueued
onto each of the queues currently bound to the address (as well as the
automatically created queue with the same name as the address, which now
accumulates messages sent to that address not only by senders explicitly
requesting anycast behaviour, but also those from senders declaring multicast
behaviour). I.e. they are *not* actually being routed with anycast semantics.
If my receiver to the named subscription queue exists and reconnects, it now
gets an error from the broker 'Incorrect Routing Type for queue, expecting:
ANYCAST'
To me this seems pretty broken behaviour.
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-2148) getDoubleProperty changes the message
[ https://issues.apache.org/jira/browse/ARTEMIS-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Bertram resolved ARTEMIS-2148. - Resolution: Fixed > getDoubleProperty changes the message > - > > Key: ARTEMIS-2148 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > This is really a typo: > > MessageImpl::getDoubleProperty(SimpleString) is marking the body to be > changed. > > I don't foresee many issues around this, but i wanted to register the fix as > a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664128#comment-16664128
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@grs
On 2. I disagree if producer explicitly sets a routing type, it must be
honoured.
Rr defaults these only should be used if producer does not explicitly set.
@franz1981 your newer implementation looks better, in that it only sets the
type if not explicitly set. +1
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2123) Paging not stopped if there are no messages on one subscription
[ https://issues.apache.org/jira/browse/ARTEMIS-2123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16664127#comment-16664127 ] ASF GitHub Bot commented on ARTEMIS-2123: - Github user clebertsuconic commented on the issue: https://github.com/apache/activemq-artemis/pull/2369 @wy96f are you waiting a release to apply your patch? > Paging not stopped if there are no messages on one subscription > --- > > Key: ARTEMIS-2123 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2123 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: Broker >Affects Versions: 2.6.3 >Reporter: yangwei >Priority: Major > > Reproduction steps: > # create a topic t and two subscriptions ta, tb > # send messages to ta and tb > # create ta consumers and receive all messages from ta > # close consumers > # only send message to tb > # create tb consumers and receive all message from tb > # topic not stopped paging -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ARTEMIS-1710) Allow for management messages to pass the global-max-size limit
[ https://issues.apache.org/jira/browse/ARTEMIS-1710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Nigro reassigned ARTEMIS-1710: Assignee: Francesco Nigro > Allow for management messages to pass the global-max-size limit > --- > > Key: ARTEMIS-1710 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1710 > Project: ActiveMQ Artemis > Issue Type: Bug >Reporter: Ulf Lilleengen >Assignee: Francesco Nigro >Priority: Major > > Use case: global-max-size is set to some limit to prevent the broker from > falling over. The broker is configured with N queues which are all blocked by > this limit. > If this limit is reached, however, it is not possible to perform management > operations on the broker, so you're stuck. > > It should be possible to have an address like 'activemq.management' bypass > this limit so that a broker can be recovered when the global-max-size is > reached. > > To work around the problem, an external component needs to ensure that all > addresses created have a max-size-bytes set so that worst case, there is some > room left for 'activemq.management' address. In this case the broker > configuration needs to be known by the component creating addresses which is > impractical and it feels like this problem would be easier to solve inside > the broker. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7086) KahaDB - don't perform expensive gc run on shutdown
[ https://issues.apache.org/jira/browse/AMQ-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663888#comment-16663888 ] Jeff Genender commented on AMQ-7086: [~gtully] my .02 is making it configurable is the way to go. > KahaDB - don't perform expensive gc run on shutdown > --- > > Key: AMQ-7086 > URL: https://issues.apache.org/jira/browse/AMQ-7086 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > when looking at the speed of broker.stop with kahadb and the scheduler store. > There is a full gc run, which can be expensive as the whole index needs to be > traversed. > Fast stop/restart is important for fast failover. Leaving gc for runtime, > where it has an effect on latency in the normal way, rather than > availability, is better. > > I am wondering if there is a use case for gc only at shutdown if the > cleanupInterval <= 0, indicating that there were no gc at runtime. The > alternative is adding another boolean to the config or adding that back in if > the need arises. > I am leaning towards just removing the gc call during shutdown. > > Note: matching the indexCacheSize to the index file size, trading off with > memory, does help to speed up the index (read) traversal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7083) Project website has some obsolete content
[
https://issues.apache.org/jira/browse/AMQ-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663882#comment-16663882
]
David Tonhofer commented on AMQ-7083:
-
On
[http://activemq.apache.org/activemq-5156-release.html]
suggestion to use a variable in the example: "${VERSION}" instead of an
metavariable as placeholder.
> Project website has some obsolete content
> -
>
> Key: AMQ-7083
> URL: https://issues.apache.org/jira/browse/AMQ-7083
> Project: ActiveMQ
> Issue Type: Bug
> Components: Documentation
>Reporter: David Tonhofer
>Priority: Major
>
> 1) On [http://activemq.apache.org/activemq-5156-release.html] there is still
> talk about MD5 sums whereas the hashes have moved to SHA512.
> 2) The link to the source is wrong on
> http://activemq.apache.org/activemq-5156-release.html
> Given link:
> [http://www.apache.org/dyn/closer.cgi?path=/activemq/5.15.5/activemq-parent-5.15.6-source-release.zip6]
> Correct link:
> [http://www.apache.org/dyn/closer.cgi?path=/activemq/5.15.6/activemq-parent-5.15.6-source-release.zip]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2148) getDoubleProperty changes the message
[ https://issues.apache.org/jira/browse/ARTEMIS-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663862#comment-16663862 ] ASF subversion and git services commented on ARTEMIS-2148: -- Commit 7ca84772f2f4e643ad599a4253e7cb401ae75614 in activemq-artemis's branch refs/heads/2.6.x from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=7ca8477 ] ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed (cherry picked from commit 04e278cd155de0e88ab1bea659da1a2b71e96c39) > getDoubleProperty changes the message > - > > Key: ARTEMIS-2148 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > This is really a typo: > > MessageImpl::getDoubleProperty(SimpleString) is marking the body to be > changed. > > I don't foresee many issues around this, but i wanted to register the fix as > a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2148) getDoubleProperty changes the message
[ https://issues.apache.org/jira/browse/ARTEMIS-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663860#comment-16663860 ] ASF GitHub Bot commented on ARTEMIS-2148: - Github user asfgit closed the pull request at: https://github.com/apache/activemq-artemis/pull/2394 > getDoubleProperty changes the message > - > > Key: ARTEMIS-2148 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > This is really a typo: > > MessageImpl::getDoubleProperty(SimpleString) is marking the body to be > changed. > > I don't foresee many issues around this, but i wanted to register the fix as > a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2148) getDoubleProperty changes the message
[ https://issues.apache.org/jira/browse/ARTEMIS-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663859#comment-16663859 ] ASF subversion and git services commented on ARTEMIS-2148: -- Commit 04e278cd155de0e88ab1bea659da1a2b71e96c39 in activemq-artemis's branch refs/heads/master from Clebert Suconic [ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=04e278c ] ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed > getDoubleProperty changes the message > - > > Key: ARTEMIS-2148 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > This is really a typo: > > MessageImpl::getDoubleProperty(SimpleString) is marking the body to be > changed. > > I don't foresee many issues around this, but i wanted to register the fix as > a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2148) getDoubleProperty changes the message
[ https://issues.apache.org/jira/browse/ARTEMIS-2148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663828#comment-16663828 ] ASF GitHub Bot commented on ARTEMIS-2148: - GitHub user clebertsuconic opened a pull request: https://github.com/apache/activemq-artemis/pull/2394 ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed You can merge this pull request into a Git repository by running: $ git pull https://github.com/clebertsuconic/activemq-artemis ARTEMIS-2148 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq-artemis/pull/2394.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 #2394 commit 04e278cd155de0e88ab1bea659da1a2b71e96c39 Author: Clebert Suconic Date: 2018-10-25T14:41:02Z ARTEMIS-2148 Fixing typo where getDoubleProperty marks body as changed > getDoubleProperty changes the message > - > > Key: ARTEMIS-2148 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 > Project: ActiveMQ Artemis > Issue Type: Task > Components: Broker >Affects Versions: 2.6.3 >Reporter: clebert suconic >Priority: Major > Fix For: 2.7.0, 2.6.4 > > > This is really a typo: > > MessageImpl::getDoubleProperty(SimpleString) is marking the body to be > changed. > > I don't foresee many issues around this, but i wanted to register the fix as > a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2148) getDoubleProperty changes the message
clebert suconic created ARTEMIS-2148: Summary: getDoubleProperty changes the message Key: ARTEMIS-2148 URL: https://issues.apache.org/jira/browse/ARTEMIS-2148 Project: ActiveMQ Artemis Issue Type: Task Components: Broker Affects Versions: 2.6.3 Reporter: clebert suconic Fix For: 2.7.0, 2.6.4 This is really a typo: MessageImpl::getDoubleProperty(SimpleString) is marking the body to be changed. I don't foresee many issues around this, but i wanted to register the fix as a Jira here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (AMQ-7083) Project website has some obsolete content
[ https://issues.apache.org/jira/browse/AMQ-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663791#comment-16663791 ] David Tonhofer commented on AMQ-7083: - [http://activemq.apache.org/how-can-i-monitor-activemq.html] Dead links: * [HermesJMS|http://www.hermesjms.com/confluence/display/HJMS/Home] * [Geronimo Administration Console|https://cwiki.apache.org/GMOxDOC11/geronimo-administration-console.html#GeronimoAdministrationConsole-JMSServer] (JMS Resources) * [FuseHQ|http://fusesource.com/products/fuse-hq/] (based on Hyperic HQ Enterprise) - Not sure whether [https://developers.redhat.com/products/fuse/overview/] would be replacement link * [iTKO LISA Test|http://www.itko.com/products/jms.jsp] > Project website has some obsolete content > - > > Key: AMQ-7083 > URL: https://issues.apache.org/jira/browse/AMQ-7083 > Project: ActiveMQ > Issue Type: Bug > Components: Documentation >Reporter: David Tonhofer >Priority: Major > > 1) On [http://activemq.apache.org/activemq-5156-release.html] there is still > talk about MD5 sums whereas the hashes have moved to SHA512. > 2) The link to the source is wrong on > http://activemq.apache.org/activemq-5156-release.html > Given link: > [http://www.apache.org/dyn/closer.cgi?path=/activemq/5.15.5/activemq-parent-5.15.6-source-release.zip6] > Correct link: > [http://www.apache.org/dyn/closer.cgi?path=/activemq/5.15.6/activemq-parent-5.15.6-source-release.zip] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-2146) Broker throws exception and becomes unresponsive during AMQP messaging
[
https://issues.apache.org/jira/browse/ARTEMIS-2146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
clebert suconic closed ARTEMIS-2146.
> Broker throws exception and becomes unresponsive during AMQP messaging
> --
>
> Key: ARTEMIS-2146
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2146
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.6.3
>Reporter: Timothy Bish
>Assignee: clebert suconic
>Priority: Major
> Fix For: 2.7.0, 2.6.4
>
>
> While testing two different AMQP clients communicating on a single broker
> instance the broker can throw the below error and become crippled afterwards
> requiring a restart to get back to normal operation.
> {noformat}
> 2018-10-23 10:29:49,863 INFO [org.apache.activemq.artemis.core.server]
> AMQ221007: Server is now live
> 2018-10-23 10:29:49,863 INFO [org.apache.activemq.artemis.core.server]
> AMQ221001: Apache ActiveMQ Artemis Message Broker version 2.7.0-SNAPSHOT
> [0.0.0.0, nodeID=18aef23b-d6d0-11e8-b6ff-2c56dc3896a2]
> 2018-10-23 10:29:50,008 INFO
> [org.apache.activemq.hawtio.branding.PluginContextListener] Initialized
> activemq-branding plugin
> 2018-10-23 10:29:50,042 INFO
> [org.apache.activemq.hawtio.plugin.PluginContextListener] Initialized
> artemis-plugin plugin
> 2018-10-23 10:29:50,247 INFO [io.hawt.HawtioContextListener] Initialising
> hawtio services
> 2018-10-23 10:29:50,257 INFO [io.hawt.system.ConfigManager] Configuration
> will be discovered via system properties
> 2018-10-23 10:29:50,259 INFO [io.hawt.jmx.JmxTreeWatcher] Welcome to hawtio
> 1.5.5 : http://hawt.io/ : Don't cha wish your console was hawt like me? ;-)
> 2018-10-23 10:29:50,261 INFO [io.hawt.jmx.UploadManager] Using file upload
> directory: /home/timothy/dev/activemq-artemis/amqp/tmp/uploads
> 2018-10-23 10:29:50,272 INFO [io.hawt.web.AuthenticationFilter] Starting
> hawtio authentication filter, JAAS realm: "activemq" authorized role(s):
> "amq" role principal classes:
> "org.apache.activemq.artemis.spi.core.security.jaas.RolePrincipal"
> 2018-10-23 10:29:50,293 INFO [io.hawt.web.JolokiaConfiguredAgentServlet]
> Jolokia overridden property: [key=policyLocation,
> value=file:/home/timothy/dev/activemq-artemis/amqp/etc/jolokia-access.xml]
> 2018-10-23 10:29:50,311 INFO [io.hawt.web.RBACMBeanInvoker] Using MBean
> [hawtio:type=security,area=jmx,rank=0,name=HawtioDummyJMXSecurity] for role
> based access control
> 2018-10-23 10:29:50,521 INFO [io.hawt.system.ProxyWhitelist] Initial proxy
> whitelist: [localhost, 127.0.0.1, 192.168.2.150, 10.10.124.116,
> ovpn-124-116.rdu2.redhat.com]
> 2018-10-23 10:29:50,666 INFO [org.apache.activemq.artemis] AMQ241001: HTTP
> Server started at http://localhost:8161
> 2018-10-23 10:29:50,666 INFO [org.apache.activemq.artemis] AMQ241002:
> Artemis Jolokia REST API available at http://localhost:8161/console/jolokia
> 2018-10-23 10:29:50,666 INFO [org.apache.activemq.artemis] AMQ241004:
> Artemis Console available at http://localhost:8161/console
> 2018-10-23 10:37:53,162 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=0, filter=null, binding=LocalQueueBinding
> [address=q0, queue=QueueImpl[name=q0, postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=18aef23b-d6d0-11e8-b6ff-2c56dc3896a2],
> temp=false]@31eabbcf, filter=null, name=q0,
> clusterName=q018aef23b-d6d0-11e8-b6ff-2c56dc3896a2]],
> message=Reference[4080]:NON-RELIABLE:AMQPMessage [durable=false,
> messageID=4080, address=q0, size=271, applicationProperties=null,
> properties=Properties{messageId=ID:822fd816-a7dc-4a54-a39f-ea9798995135:1:1:1-1,
> userId=null, to='q0', subject='null', replyTo='null', correlationId=null,
> contentType=application/octet-stream, contentEncoding=null,
> absoluteExpiryTime=null, creationTime=null, groupId='null',
> groupSequence=null, replyToGroupId='null'}, extraProperties =
> TypedProperties[_AMQ_AD=q0]]: java.lang.NullPointerException
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.handle(ServerConsumerImpl.java:352)
> [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.handle(QueueImpl.java:3173)
> [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2515)
> [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2100(QueueImpl.java:111)
> [artemis-server-2.7.0-SNAPSHOT.jar:2.7.0-SNAPSHOT]
> at
> org.apache.activemq.artemis.core.server
[jira] [Commented] (AMQ-7086) KahaDB - don't perform expensive gc run on shutdown
[ https://issues.apache.org/jira/browse/AMQ-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663646#comment-16663646 ] Gary Tully commented on AMQ-7086: - The checkpoint=0 use case is from: AMQ-3646 disabling gc on shutdown will need to be configurable I think. > KahaDB - don't perform expensive gc run on shutdown > --- > > Key: AMQ-7086 > URL: https://issues.apache.org/jira/browse/AMQ-7086 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > when looking at the speed of broker.stop with kahadb and the scheduler store. > There is a full gc run, which can be expensive as the whole index needs to be > traversed. > Fast stop/restart is important for fast failover. Leaving gc for runtime, > where it has an effect on latency in the normal way, rather than > availability, is better. > > I am wondering if there is a use case for gc only at shutdown if the > cleanupInterval <= 0, indicating that there were no gc at runtime. The > alternative is adding another boolean to the config or adding that back in if > the need arises. > I am leaning towards just removing the gc call during shutdown. > > Note: matching the indexCacheSize to the index file size, trading off with > memory, does help to speed up the index (read) traversal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7086) KahaDB - don't perform expensive gc run on shutdown
[ https://issues.apache.org/jira/browse/AMQ-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-7086: Description: when looking at the speed of broker.stop with kahadb and the scheduler store. There is a full gc run, which can be expensive as the whole index needs to be traversed. Fast stop/restart is important for fast failover. Leaving gc for runtime, where it has an effect on latency in the normal way, rather than availability, is better. I am wondering if there is a use case for gc only at shutdown if the cleanupInterval <= 0, indicating that there were no gc at runtime. The alternative is adding another boolean to the config or adding that back in if the need arises. I am leaning towards just removing the gc call during shutdown. Note: matching the indexCacheSize to the index file size, trading off with memory, does help to speed up the index (read) traversal. was: when looking at the speed of broker.stop with kahadb and the scheduler store. There is a full gc run, which can be expensive as the whole index needs to be traversed. Fast stop/restart is important for fast failover. Leaving gc for runtime, where it has an effect on latency rather than availability is better. I am wondering if there is a use case for gc only at shutdown if the cleanupInterval <= 0, indicating that there were no gc at runtime. The alternative is adding another boolean to the config or adding that back in if the need arises. I am leaning towards just removing the gc call during shutdown. Note: matching the indexCacheSize to the index file size, trading off with memory, does help to speed up the index (read) traversal. > KahaDB - don't perform expensive gc run on shutdown > --- > > Key: AMQ-7086 > URL: https://issues.apache.org/jira/browse/AMQ-7086 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > when looking at the speed of broker.stop with kahadb and the scheduler store. > There is a full gc run, which can be expensive as the whole index needs to be > traversed. > Fast stop/restart is important for fast failover. Leaving gc for runtime, > where it has an effect on latency in the normal way, rather than > availability, is better. > > I am wondering if there is a use case for gc only at shutdown if the > cleanupInterval <= 0, indicating that there were no gc at runtime. The > alternative is adding another boolean to the config or adding that back in if > the need arises. > I am leaning towards just removing the gc call during shutdown. > > Note: matching the indexCacheSize to the index file size, trading off with > memory, does help to speed up the index (read) traversal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (AMQ-7086) KahaDB - don't perform expensive gc run on shutdown
[ https://issues.apache.org/jira/browse/AMQ-7086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Tully updated AMQ-7086: Description: when looking at the speed of broker.stop with kahadb and the scheduler store. There is a full gc run, which can be expensive as the whole index needs to be traversed. Fast stop/restart is important for fast failover. Leaving gc for runtime, where it has an effect on latency rather than availability is better. I am wondering if there is a use case for gc only at shutdown if the cleanupInterval <= 0, indicating that there were no gc at runtime. The alternative is adding another boolean to the config or adding that back in if the need arises. I am leaning towards just removing the gc call during shutdown. Note: matching the indexCacheSize to the index file size, trading off with memory, does help to speed up the index (read) traversal. was: when looking at the speed of broker.stop with kahadb and the scheduler store. There is a full gc run, which can be expensive as the whole index needs to be traversed. Fast stop/restart is important for fast failover. Leaving gc for to runtime, where it has an effect on latency rather than availability is better. I am wondering if there is a use case for gc only at shutdown if the cleanupInterval <= 0, indicating that there were no gc at runtime. The alternative is adding another boolean to the config or adding that back in if the need arises. I am leaning towards just removing the gc call during shutdown. Note: matching the indexCacheSize to the index file size, trading off with memory, does help to speed up the index (read) traversal. > KahaDB - don't perform expensive gc run on shutdown > --- > > Key: AMQ-7086 > URL: https://issues.apache.org/jira/browse/AMQ-7086 > Project: ActiveMQ > Issue Type: Bug > Components: KahaDB >Affects Versions: 5.15.0 >Reporter: Gary Tully >Assignee: Gary Tully >Priority: Major > Fix For: 5.16.0 > > > when looking at the speed of broker.stop with kahadb and the scheduler store. > There is a full gc run, which can be expensive as the whole index needs to be > traversed. > Fast stop/restart is important for fast failover. Leaving gc for runtime, > where it has an effect on latency rather than availability is better. > > I am wondering if there is a use case for gc only at shutdown if the > cleanupInterval <= 0, indicating that there were no gc at runtime. The > alternative is adding another boolean to the config or adding that back in if > the need arises. > I am leaning towards just removing the gc call during shutdown. > > Note: matching the indexCacheSize to the index file size, trading off with > memory, does help to speed up the index (read) traversal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (AMQ-7086) KahaDB - don't perform expensive gc run on shutdown
Gary Tully created AMQ-7086: --- Summary: KahaDB - don't perform expensive gc run on shutdown Key: AMQ-7086 URL: https://issues.apache.org/jira/browse/AMQ-7086 Project: ActiveMQ Issue Type: Bug Components: KahaDB Affects Versions: 5.15.0 Reporter: Gary Tully Assignee: Gary Tully Fix For: 5.16.0 when looking at the speed of broker.stop with kahadb and the scheduler store. There is a full gc run, which can be expensive as the whole index needs to be traversed. Fast stop/restart is important for fast failover. Leaving gc for to runtime, where it has an effect on latency rather than availability is better. I am wondering if there is a use case for gc only at shutdown if the cleanupInterval <= 0, indicating that there were no gc at runtime. The alternative is adding another boolean to the config or adding that back in if the need arises. I am leaning towards just removing the gc call during shutdown. Note: matching the indexCacheSize to the index file size, trading off with memory, does help to speed up the index (read) traversal. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663563#comment-16663563
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce I think to have misread the issue: the current
behaviour is not bad, just is not taking in consideration the already existing
address routingType(s) and just choosing the default one when no specific
routingType is being requested...I will soon push a commit with a different way
to address it
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663540#comment-16663540
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
Two points:
1) in my case, accessing over AMQP, the sender is *not* defining any
routing type
2) I would not expect a sender requesting a routing type explicitly to
redefine a statically defined address i.e. if address pre-exists and has
routing types only multicast, a sender attempting to request anycast should be
informed that their intentions do not match the pre-configured semantics (of
course if the address does not exist then it can be defined according to the
senders desires providing auto-creation of the address is allowed).
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663532#comment-16663532
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user michaelandrepearce commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
Point here is if the sender has specifically defined that has to be
honoured.
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663504#comment-16663504
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user grs commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce @franz1981 the issue is that if an address is defined
to be multicast only, then a sender to it over AMQP causes the address to be
redefined as multicast and anycast *and* a queue is created with the same name
as the address, meaning that all other use of that address over AMQP now uses
the queue. What I want is the ability to define an address that reliably
behaves as a topic.
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-2100) address routing-type overridden on attaching AMQP sender
[
https://issues.apache.org/jira/browse/ARTEMIS-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16663503#comment-16663503
]
ASF GitHub Bot commented on ARTEMIS-2100:
-
Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2392
@michaelandrepearce I understand your point here, just I'm not sure is only
a matter of flexibility here, but more of user expectations and I admit that it
makes this a lot more subjective to be judged.
The point of the issue is that if an address already exists, but without
any queue on it, which routing type configuration will take precendence while
creating a new one?
For some users It could be the default routing type specified on the
addresses settings, while for others the ones defined in the already existing
address.
I admit that I'm more of the idea that the latter is matching most user
expectations, but is just a personal taste.
> address routing-type overridden on attaching AMQP sender
>
>
> Key: ARTEMIS-2100
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2100
> Project: ActiveMQ Artemis
> Issue Type: Bug
>Affects Versions: 2.6.2
>Reporter: Gordon Sim
>Priority: Major
> Fix For: 2.6.4
>
>
> If the default-address-routing-type is set to ANYCAST and an address is
> created with routing-type MULTICAST, then when an AMQP sender attaches to
> that address the address is recreated with routing-type=[MULTICAST,ANYCAST]
> and a queue with the same name as the address is created. It is expected that
> the address routing-type should be honoured.
> E.g. on broker with:
> {noformat}
>
> DLQ
> ExpiryQueue
> 0
>
> -1
>
> 10
> PAGE
> true
> true
> true
> true
>
> ANYCAST
>
> {noformat}
> Create a MULTICAST address:
> {noformat}
> artemis address create --multicast --no-anycast --name mytopic
> {noformat}
> Check the address and any queues (feilds ommitted for clarity):
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|activemq.management.612e33f1-1c5f-4bde-99bb-9e9188efa508|1
>
> {noformat}
> Now attach an AMQP sender to the address, e.g. using Qpid Proton python
> example
> {noformat}
> simple_send.py -a localhost/mytopic -m 1
> {noformat}
> Now the address has been altered and a queue called mytopic exists:
> {noformat}
> $ artemis address show --name mytopic
> Address [name=mytopic, routingTypes={MULTICAST,ANYCAST}, autoCreated=false]
> $ artemis queue stat
> |NAME |ADDRESS
> |DLQ |DLQ
> |ExpiryQueue |ExpiryQueue
> |activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5|activemq.management.5a393c3e-746d-404b-9afb-36849886aaa5
> |mytopic |mytopic
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
