[jira] [Commented] (ARTEMIS-2172) Broker drops connection during throughput test
[
https://issues.apache.org/jira/browse/ARTEMIS-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750820#comment-16750820
]
Simon Chalmers commented on ARTEMIS-2172:
-
Hi [[~clebertsuconic] my colleague Rachel will be taking over this testing and
analysis work now on the Artemis from our side.
She will jump in here shortly and update the JIRA accordingly.
> Broker drops connection during throughput test
> --
>
> Key: ARTEMIS-2172
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2172
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.7.0, 2.6.3
> Environment: * Host OS: Linux node1 4.9.0-8-amd64 #1 SMP Debian
> 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux
> * Dotnet2.1 SDK installed as per these instructions:
> https://www.microsoft.com/net/download/linux-package-manager/debian9/sdk-current
> * Test client attached, to run the test: dotnet AmqpBrokerThroughputTest.dll
> -h -u -p , e.g. dotnet AmqpBrokerThroughputTest.dll
> -h 172.31.0.175 -u mimqadmin -p dogcat123
> * Broker.xml attached.
>Reporter: Simon Chalmers
>Priority: Major
> Attachments: AmqpBrokerThroughputTest.zip, broker.xml
>
>
> When running a continual test against a broker setup as a master-slave, after
> an arbitrary length of time, the test client disconnects and stops working.
> The only message thrown in the artemis.log file is:
> {{2018-10-31 09:32:07,368 WARN [org.apache.activemq.artemis.core.client]
> AMQ212037: Connection failure has been detected: AMQ229014: Did not receive
> data from /172.31.15.214:38325 within the 60,000ms connection TTL. The
> connection will now be closed. [code=CONNECTION_TIMEDOUT]
> 2018-10-31 09:32:07,370 WARN [org.apache.activemq.artemis.core.server]
> AMQ222061: Client connection failed, clearing up resources for session
> 4610a425-dcbf-11e8-b83f-0284a4757140
> 2018-10-31 09:32:07,371 WARN [org.apache.activemq.artemis.core.server]
> AMQ222107: Cleared up resources for session
> 4610a425-dcbf-11e8-b83f-0284a4757140}}
> I wondered if this issue (https://issues.apache.org/jira/browse/ARTEMIS-2146)
> was related, but I tried the test against 2.6.x and the same result happened.
> I've tried it against the current version 2.6.3 and the 2.6.x master in
> github.
> Question: Is there more information available to see why a connection failed?
--
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=16750821#comment-16750821
]
Simon Chalmers commented on ARTEMIS-2113:
-
HI [~clebertsuconic] - my colleague Rachel will be taking over this testing and
analysis work now on the Artemis from our side.
She will jump in here shortly and update the JIRA accordingly.
> 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)
>
[jira] [Commented] (ARTEMIS-2180) Host and broker runs out of memory when stopping a backup in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16750819#comment-16750819 ] Simon Chalmers commented on ARTEMIS-2180: - HI [~jbertram] - my colleague Rachel will be taking over this testing and analysis work now on the Artemis from our side. She will jump in here shortly and update the JIRA accordingly. > Host and broker runs out of memory when stopping a backup in a cluster > -- > > Key: ARTEMIS-2180 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2180 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Simon Chalmers >Priority: Critical > Attachments: hs_err_pid15534.log > > > When running a live-backup cluster pair and stopping the backup, the live > broker starts leaking memory, runs out of memory and core dumps. > This occurs during a performance test when the broker is under load; the > slave has been running successfully but is then terminated whilst the broker > is still under load. > Core dump attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-2180) Host and broker runs out of memory when stopping a backup in a cluster
[ https://issues.apache.org/jira/browse/ARTEMIS-2180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-2180: Description: When running a live-backup cluster pair and stopping the backup, the live broker starts leaking memory, runs out of memory and core dumps. This occurs during a performance test when the broker is under load; the slave has been running successfully but is then terminated whilst the broker is still under load. Core dump attached. was: When running a live-backup cluster pair and stopping the backup, the live broker starts leaking memory, runs of memory and core dumps. Core dump attached. > Host and broker runs out of memory when stopping a backup in a cluster > -- > > Key: ARTEMIS-2180 > URL: https://issues.apache.org/jira/browse/ARTEMIS-2180 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.6.3 >Reporter: Simon Chalmers >Priority: Critical > Attachments: hs_err_pid15534.log > > > When running a live-backup cluster pair and stopping the backup, the live > broker starts leaking memory, runs out of memory and core dumps. > This occurs during a performance test when the broker is under load; the > slave has been running successfully but is then terminated whilst the broker > is still under load. > Core dump attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2180) Host and broker runs out of memory when stopping a backup in a cluster
Simon Chalmers created ARTEMIS-2180: --- Summary: Host and broker runs out of memory when stopping a backup in a cluster Key: ARTEMIS-2180 URL: https://issues.apache.org/jira/browse/ARTEMIS-2180 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.6.3 Reporter: Simon Chalmers Attachments: hs_err_pid15534.log When running a live-backup cluster pair and stopping the backup, the live broker starts leaking memory, runs of memory and core dumps. Core dump attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-2172) Broker drops connection during throughput test
Simon Chalmers created ARTEMIS-2172:
---
Summary: Broker drops connection during throughput test
Key: ARTEMIS-2172
URL: https://issues.apache.org/jira/browse/ARTEMIS-2172
Project: ActiveMQ Artemis
Issue Type: Bug
Components: AMQP
Affects Versions: 2.6.3, 2.7.0
Environment: * Host OS: Linux node1 4.9.0-8-amd64 #1 SMP Debian
4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux
* Dotnet2.1 SDK installed as per these instructions:
https://www.microsoft.com/net/download/linux-package-manager/debian9/sdk-current
* Test client attached, to run the test: dotnet AmqpBrokerThroughputTest.dll -h
-u -p , e.g. dotnet AmqpBrokerThroughputTest.dll -h
172.31.0.175 -u mimqadmin -p dogcat123
* Broker.xml attached.
Reporter: Simon Chalmers
Attachments: AmqpBrokerThroughputTest.zip, broker.xml
When running a continual test against a broker setup as a master-slave, after
an arbitrary length of time, the test client disconnects and stops working. The
only message thrown in the artemis.log file is:
{{2018-10-31 09:32:07,368 WARN [org.apache.activemq.artemis.core.client]
AMQ212037: Connection failure has been detected: AMQ229014: Did not receive
data from /172.31.15.214:38325 within the 60,000ms connection TTL. The
connection will now be closed. [code=CONNECTION_TIMEDOUT]
2018-10-31 09:32:07,370 WARN [org.apache.activemq.artemis.core.server]
AMQ222061: Client connection failed, clearing up resources for session
4610a425-dcbf-11e8-b83f-0284a4757140
2018-10-31 09:32:07,371 WARN [org.apache.activemq.artemis.core.server]
AMQ222107: Cleared up resources for session
4610a425-dcbf-11e8-b83f-0284a4757140}}
I wondered if this issue (https://issues.apache.org/jira/browse/ARTEMIS-2146)
was related, but I tried the test against 2.6.x and the same result happened.
I've tried it against the current version 2.6.3 and the 2.6.x master in github.
Question: Is there more information available to see why a connection failed?
--
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=16683319#comment-16683319
]
Simon Chalmers commented on ARTEMIS-2113:
-
[~clebertsuconic] Apparently this issue is not there with ActiveMQ 5.15.0
See https://github.com/Azure/amqpnetlite/issues/303 and search the page for
“ActiveMQ” and you’ll find the reference.
Let me know what else I can provide here?
> 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)
>
[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=16670986#comment-16670986
]
Simon Chalmers commented on ARTEMIS-2113:
-
[~clebertsuconic] is there a way to test that?
> 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
>
[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=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)
>
[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
[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)
[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=16658436#comment-16658436
]
Simon Chalmers commented on ARTEMIS-2113:
-
If we were able to provide a sample test app, which could be run on a Linux
environment would that assist in further discussion on this issue?
A simple 64bit Linux enviroment, such as Debian, Ubuntu, Amazon Linux et al,
along with the .NET 2.1 SDK would be all that is required to run the sample
test app and reproduce the error.
> 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
>
> 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)
>
[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:
Summary: 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 (was: Artemis doesn’t always respond with attach/detach frames
confirming the opening/closing of the links)
> 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
>
> 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}
>
[jira] [Updated] (ARTEMIS-2113) 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:
Description:
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}
was:
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)
[jira] [Updated] (ARTEMIS-2113) 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:
Description:
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 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}
was:
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)
[jira] [Updated] (ARTEMIS-2113) 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:
Description:
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 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}
was:
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.
{code:java}
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)
[jira] [Updated] (ARTEMIS-2113) 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:
Description:
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.
{code:java}
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}
{code}
Note that this doesn’t always happen. Sometimes Artemis does respond, as shown
by the lines highlighted in grey in the trace below.
{code:java}
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}
{code}
was:
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.
{code:java}
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)
[jira] [Updated] (ARTEMIS-2113) 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:
Description:
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.
{code:java}
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])
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)
RECV (ch=0)
begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty
{code}
Note that this doesn’t always happen. Sometimes Artemis does respond, as shown
by the lines highlighted in grey in the trace below.
{code:java}
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)
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)
RECV (ch=0)
attach(name:link1,handle:0,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:q1))
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)
RECV (ch=0) detach(handle:0,closed:True)
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) empty
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty
{code}
was:
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)
[jira] [Created] (ARTEMIS-2113) Artemis doesn’t always respond with attach/detach frames confirming the opening/closing of the links
Simon Chalmers created ARTEMIS-2113:
---
Summary: 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
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])
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)
RECV (ch=0)
begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535)
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty}}
Note that this doesn’t always happen. Sometimes Artemis does respond, as shown
by the lines highlighted in 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)
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)
RECV (ch=0)
attach(name:link1,handle:0,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:q1))
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)
RECV (ch=0) detach(handle:0,closed:True)
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) empty
SEND (ch=0) empty
SEND (ch=0) empty
SEND (ch=0) empty
}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1973) Consumers connected but not consuming messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16542418#comment-16542418 ] Simon Chalmers commented on ARTEMIS-1973: - Bad code. :) > Consumers connected but not consuming messages > -- > > Key: ARTEMIS-1973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.2 > Environment: Broker configuration attached as broker.xml >Reporter: Simon Chalmers >Priority: Blocker > Attachments: broker.xml > > > We have set up a number of queues, written message to those queues and then > we can see the consumers connected to the broker but they are not consuming > the messages from the queues. > When we restart the broker, the consumers now start processing and consuming > the messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (ARTEMIS-1973) Consumers connected but not consuming messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers closed ARTEMIS-1973. --- Resolution: Not A Problem > Consumers connected but not consuming messages > -- > > Key: ARTEMIS-1973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.2 > Environment: Broker configuration attached as broker.xml >Reporter: Simon Chalmers >Priority: Blocker > Attachments: broker.xml > > > We have set up a number of queues, written message to those queues and then > we can see the consumers connected to the broker but they are not consuming > the messages from the queues. > When we restart the broker, the consumers now start processing and consuming > the messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1973) Consumers connected but not consuming messages
[ https://issues.apache.org/jira/browse/ARTEMIS-1973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1973: Attachment: broker.xml > Consumers connected but not consuming messages > -- > > Key: ARTEMIS-1973 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1973 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.2 > Environment: Broker configuration attached as broker.xml >Reporter: Simon Chalmers >Priority: Blocker > Attachments: broker.xml > > > We have set up a number of queues, written message to those queues and then > we can see the consumers connected to the broker but they are not consuming > the messages from the queues. > When we restart the broker, the consumers now start processing and consuming > the messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1953) Fix Object conversions for AMQP LargeMessages
[ https://issues.apache.org/jira/browse/ARTEMIS-1953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1953: Attachment: broker.xml > Fix Object conversions for AMQP LargeMessages > - > > Key: ARTEMIS-1953 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1953 > Project: ActiveMQ Artemis > Issue Type: Improvement >Affects Versions: 2.6.2 >Reporter: clebert suconic >Assignee: clebert suconic >Priority: Blocker > Fix For: 2.7.0 > > Attachments: broker.xml > > > We should not convert AMQP messages just because they are large. WE should > for now just embed it on the file. And at a later point do proper streaming. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1973) Consumers connected but not consuming messages
Simon Chalmers created ARTEMIS-1973: --- Summary: Consumers connected but not consuming messages Key: ARTEMIS-1973 URL: https://issues.apache.org/jira/browse/ARTEMIS-1973 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP, Broker Affects Versions: 2.6.2 Environment: Broker configuration attached as broker.xml Reporter: Simon Chalmers We have set up a number of queues, written message to those queues and then we can see the consumers connected to the broker but they are not consuming the messages from the queues. When we restart the broker, the consumers now start processing and consuming the messages. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1955) Not all AMQP headers are mapped in AMQPCoreConverter
Simon Chalmers created ARTEMIS-1955: --- Summary: Not all AMQP headers are mapped in AMQPCoreConverter Key: ARTEMIS-1955 URL: https://issues.apache.org/jira/browse/ARTEMIS-1955 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.6.2 Reporter: Simon Chalmers >From here: https://github.com/apache/activemq-artemis/blob/2c8b6b4aee7b03f2872f04f1d8caaa9d85436216/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/AmqpCoreConverter.java#L111-L177 It doesn't look like you're NOT mapping all the available AMQP headers to your internal message representation, specifically you're only doing 4 out of ~20 Your set: populateMessage(result, message.getProtonMessage()); result.getInnerMessage().setReplyTo(message.getReplyTo()); result.getInnerMessage().setDurable(message.isDurable()); result.getInnerMessage().setPriority(message.getPriority()); result.getInnerMessage().setAddress(message.getAddressSimpleString()); The full header set for AMQP: http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format So if someone were expecting their AMQP headers to be carried across, they would be lost. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1928) Message conversion on certain body types will cause NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521842#comment-16521842
]
Simon Chalmers commented on ARTEMIS-1928:
-
Also, from here:
https://github.com/apache/activemq-artemis/blob/2c8b6b4aee7b03f2872f04f1d8caaa9d85436216/artemis-protocols/artemis-amqp-protocol/src/main/java/org/apache/activemq/artemis/protocol/amqp/converter/AmqpCoreConverter.java#L111-L177
It doesn't look like you're NOT mapping all the available AMQP headers to your
internal message representation, specifically you're only doing 4 out of ~20
Your set:
populateMessage(result, message.getProtonMessage());
result.getInnerMessage().setReplyTo(message.getReplyTo());
result.getInnerMessage().setDurable(message.isDurable());
result.getInnerMessage().setPriority(message.getPriority());
result.getInnerMessage().setAddress(message.getAddressSimpleString());
The full header set for AMQP:
http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#section-message-format
> Message conversion on certain body types will cause NPE
> ---
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Fix For: 2.7.0, 2.6.3
>
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
>
[jira] [Commented] (ARTEMIS-1928) Message conversion on certain body types will cause NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521838#comment-16521838
]
Simon Chalmers commented on ARTEMIS-1928:
-
Also, FYI, the content type in the AMQP message header is
application/x-protobuf.
> Message conversion on certain body types will cause NPE
> ---
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Fix For: 2.7.0, 2.6.3
>
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [rt.jar:1.8.0_171]
> at
>
[jira] [Commented] (ARTEMIS-1928) Message conversion on certain body types will cause NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521757#comment-16521757
]
Simon Chalmers commented on ARTEMIS-1928:
-
And just to clarify, are you suggesting I load up 2.6.3 or 2.7.0 now as well?
Or leave 2.6.2 running and play with the tuning of
200K ?
> Message conversion on certain body types will cause NPE
> ---
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Fix For: 2.7.0, 2.6.3
>
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [rt.jar:1.8.0_171]
>
[jira] [Commented] (ARTEMIS-1928) Message conversion on certain body types will cause NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521750#comment-16521750
]
Simon Chalmers commented on ARTEMIS-1928:
-
The message body type is a Data section containing opaque binary data
(descriptor code 0x75) as described in Section 3.2.6 of Part 3 of the AMQP
specification
(http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-messaging-v1.0-csprd01.html).
> Message conversion on certain body types will cause NPE
> ---
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Fix For: 2.7.0, 2.6.3
>
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
>
[jira] [Commented] (ARTEMIS-1928) Message conversion on certain body types will cause NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16521023#comment-16521023
]
Simon Chalmers commented on ARTEMIS-1928:
-
The devs tell me the messages are ~100kb each, no bigger. So I wouldn't assume
that hits the large message size?
What does this mean: "...or use a supported type on the converter."
> Message conversion on certain body types will cause NPE
> ---
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Fix For: 2.7.0, 2.6.3
>
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
>
[jira] [Comment Edited] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516485#comment-16516485
]
Simon Chalmers edited comment on ARTEMIS-1928 at 6/19/18 12:19 AM:
---
Using the 2.6.2 release from here:
https://github.com/apache/activemq-artemis/releases/tag/2.6.2
Same NPE thrown:
{noformat}
2018-06-19 00:16:50,403 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=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
postOffice=PostOfficeImpl
[server=ActiveMQServerImpl::serverUUID=41d444d1-7353-11e8-aacc-0204cf8299ac],
temp=false]@3bc2334a, filter=null,
name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks41d444d1-7353-11e8-aacc-0204cf8299ac]],
message=Reference[191]:NON-RELIABLE:LargeServerMessage[messageID=191,durable=false,userID=null,priority=0,
timestamp=0,expiration=0, durable=false,
address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks,
properties=TypedProperties[_AMQ_LARGE_SIZE=258279]]@1904620054:
java.lang.IllegalStateException: Can't deliver message
java.lang.NullPointerException
at
org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2938)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2406)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3211)
[artemis-server-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
[artemis-commons-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
[artemis-commons-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
[artemis-commons-2.6.2.jar:2.6.2]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_171]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_171]
at
org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118)
[artemis-commons-2.6.2.jar:2.6.2]
Caused by: java.lang.NullPointerException
at
org.apache.activemq.artemis.core.message.impl.CoreMessage.internalWritableBuffer(CoreMessage.java:360)
[artemis-core-client-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.core.message.impl.CoreMessage.getBodyBuffer(CoreMessage.java:353)
[artemis-core-client-2.6.2.jar:2.6.2]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.convertBody(CoreAmqpConverter.java:384)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:126)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:106)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.deliverMessage(ProtonServerSenderContext.java:681)
[artemis-amqp-protocol-2.6.2.jar:]
at
org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:643)
[artemis-amqp-protocol-2.6.2.jar:]
... 12 more
2018-06-19 00:16:50,425 WARN [org.apache.activemq.artemis.core.server]
AMQ222151: removing consumer which did not handle a message,
consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
[jira] [Commented] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516485#comment-16516485 ] Simon Chalmers commented on ARTEMIS-1928: - Using the 2.6.2 release from here: https://github.com/apache/activemq-artemis/releases/tag/2.6.2 Same NPE thrown: 2018-06-19 00:16:50,403 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=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, postOffice=PostOfficeImpl [server=ActiveMQServerImpl::serverUUID=41d444d1-7353-11e8-aacc-0204cf8299ac], temp=false]@3bc2334a, filter=null, name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks41d444d1-7353-11e8-aacc-0204cf8299ac]], message=Reference[191]:NON-RELIABLE:LargeServerMessage[messageID=191,durable=false,userID=null,priority=0, timestamp=0,expiration=0, durable=false, address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-leaf-bricks, properties=TypedProperties[_AMQ_LARGE_SIZE=258279]]@1904620054: java.lang.IllegalStateException: Can't deliver message java.lang.NullPointerException at org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2938) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2406) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3211) [artemis-server-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.6.2.jar:2.6.2] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_171] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_171] at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.6.2.jar:2.6.2] Caused by: java.lang.NullPointerException at org.apache.activemq.artemis.core.message.impl.CoreMessage.internalWritableBuffer(CoreMessage.java:360) [artemis-core-client-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.core.message.impl.CoreMessage.getBodyBuffer(CoreMessage.java:353) [artemis-core-client-2.6.2.jar:2.6.2] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.convertBody(CoreAmqpConverter.java:384) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.fromCore(CoreAmqpConverter.java:126) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.converter.CoreAmqpConverter.checkAMQP(CoreAmqpConverter.java:106) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.proton.ProtonServerSenderContext.deliverMessage(ProtonServerSenderContext.java:681) [artemis-amqp-protocol-2.6.2.jar:] at org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:643) [artemis-amqp-protocol-2.6.2.jar:] ... 12 more 2018-06-19 00:16:50,425 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
[jira] [Updated] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Chalmers updated ARTEMIS-1928:
Priority: Blocker (was: Critical)
> Message redistribution + AMQP causes NPE
>
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Blocker
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [rt.jar:1.8.0_171]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [rt.jar:1.8.0_171]
> at
>
[jira] [Updated] (ARTEMIS-1928) Message redistribution + AMQP causes NPE
[
https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Chalmers updated ARTEMIS-1928:
Priority: Critical (was: Major)
> Message redistribution + AMQP causes NPE
>
>
> Key: ARTEMIS-1928
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1928
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker
>Affects Versions: 2.6.1
> Environment: * Broker Version: 2.6.1
> * Client: AMQPNetLite v2.1.2
> * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1
> (2018-05-07) x86_64 GNU/Linux
> * Host Platform: AWS EC2
> * broker.xml from node1 attached as node1-broker.xml
> * broker.xml from node2 attached as node2-broker.xml
>Reporter: Simon Chalmers
>Priority: Critical
> Attachments: node1-broker.xml, node2-broker.xml
>
>
>
> Steps to produce, using a producing application (running AMQPNetLite)
> connecting to node1 of the cluster:
> * Create queue1, publish 199 messages to it
> * Create queue2, publish 1 message to it
> Running a consuming application (AMQPNetLite) connecting to node2 of the
> cluster:
> * On node1 of the cluster, queue1 & queue2 now have 0 messages in it
> * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2
> messages in it (i.e. an additional message in each queue, even though the
> consuming application is not publishing any messages).
> * The consuming application connected to node2 of the cluster does not
> consume any messages off either queue1 or queue2 from node2 (of the cluster).
> In artemis.log on node2 of the cluster, the following appears:
> {noformat}
> 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server]
> AMQ222151: removing consumer which did not handle a message,
> consumer=ServerConsumerImpl [id=1, filter=null, binding=LocalQueueBinding
> [address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> queue=QueueImpl[name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> postOffice=PostOfficeImpl
> [server=ActiveMQServerImpl::serverUUID=f80e9286-6e9f-11e8-bd64-0204cf8299ac],
> temp=false]@50517445, filter=null,
> name=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
>
> clusterName=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-requestf80e9286-6e9f-11e8-bd64-0204cf8299ac]],
>
> message=Reference[117]:NON-RELIABLE:LargeServerMessage[messageID=117,durable=false,userID=null,priority=0,
> timestamp=0,expiration=0, durable=false,
> address=internal/queue.in/spatial-processing-service/440bfafe-76e5-4867-8b00-f1533d855549/0/update-terrain-request,
> properties=TypedProperties[_AMQ_LARGE_SIZE=330649]]@2025498374:
> java.lang.IllegalStateException: Can't deliver message
> java.lang.NullPointerException
> at
> org.apache.activemq.artemis.protocol.amqp.broker.AMQPSessionCallback.sendMessage(AMQPSessionCallback.java:652)
> [artemis-amqp-protocol-2.6.1.jar:]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.deliverStandardMessage(ServerConsumerImpl.java:1106)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl.proceedDeliver(ServerConsumerImpl.java:464)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.proceedDeliver(QueueImpl.java:2934)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.deliver(QueueImpl.java:2402)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl.access$2000(QueueImpl.java:107)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.core.server.impl.QueueImpl$DeliverRunner.run(QueueImpl.java:3207)
> [artemis-server-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66)
> [artemis-commons-2.6.1.jar:2.6.1]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [rt.jar:1.8.0_171]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [rt.jar:1.8.0_171]
> at
>
[jira] [Comment Edited] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510629#comment-16510629 ] Simon Chalmers edited comment on ARTEMIS-1928 at 6/13/18 5:30 AM: -- Update: I ran the cluster up with only a single node in the cluster and ran the same steps, but obviously produced and consumed from queue1 and queue2 on the same node (node1). Outcome: Consuming application successfully consumed the messages from the queues and processed them. was (Author: auskeptic): Update: I ran the cluster up with only a single node in the cluster and ran the same steps. Outcome: Consuming application successfully consumed the messages from the queues and processed them. > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attached as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16510629#comment-16510629 ] Simon Chalmers commented on ARTEMIS-1928: - Update: I ran the cluster up with only a single node in the cluster and ran the same steps. Outcome: Consuming application successfully consumed the messages from the queues and processed them. > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attached as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1928: Environment: * Broker Version: 2.6.1 * Client: AMQPNetLite v2.1.2 * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux * Host Platform: AWS EC2 * broker.xml from node1 attached as node1-broker.xml * broker.xml from node2 attached as node2-broker.xml was: * Broker Version: 2.6.1 * Client: AMQPNetLite v2.1.2 * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux * Host Platform: AWS EC2 * broker.xml from node1 attached as node1-broker.xml * broker.xml from node2 attaches as node2-broker.xml > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attached as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1928: Description: Steps to produce, using a producing application (running AMQPNetLite) connecting to node1 of the cluster: * Create queue1, publish 199 messages to it * Create queue2, publish 1 message to it Running a consuming application (AMQPNetLite) connecting to node2 of the cluster: * On node1 of the cluster, queue1 & queue2 now have 0 messages in it * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 messages in it (i.e. an additional message in each queue, even though the consuming application is not publishing any messages). * The consuming application connected to node2 of the cluster does not consume any messages off either queue1 or queue2 from node2 (of the cluster). In artemis.log on node2 of the cluster, the following appears: 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl Full log @ [https://pastebin.com/N0Jdr0Ha] was: Steps to produce, using a producing application (running AMQPNetLite) connecting to node1 of the cluster: * Create queue1, publish 199 messages to it * Create queue2, publish 1 message to it Running a consuming application (AMQPNetLite) connecting to node2 of the cluster: * On node1 of the cluster, queue1 & queue2 now have 0 messages in it * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 messages in it (i.e. an additional message in each queue, even though the consuming application is not publishing any messages). * The consuming application connected to node2 of the cluster does not consume any messages off either queue1 or queue2 from node2 (of the cluster). In artemis.log on node2 of the cluster, the following error appears: 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl Full log @ [https://pastebin.com/N0Jdr0Ha] > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attaches as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1928: Attachment: node2-broker.xml > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attaches as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following error appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
[ https://issues.apache.org/jira/browse/ARTEMIS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1928: Attachment: node1-broker.xml > Messages in queues on other nodes in a cluster are not consumable > - > > Key: ARTEMIS-1928 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP, Broker >Affects Versions: 2.6.1 > Environment: * Broker Version: 2.6.1 > * Client: AMQPNetLite v2.1.2 > * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 > (2018-05-07) x86_64 GNU/Linux > * Host Platform: AWS EC2 > * broker.xml from node1 attached as node1-broker.xml > * broker.xml from node2 attaches as node2-broker.xml >Reporter: Simon Chalmers >Priority: Major > Attachments: node1-broker.xml, node2-broker.xml > > > > Steps to produce, using a producing application (running AMQPNetLite) > connecting to node1 of the cluster: > * Create queue1, publish 199 messages to it > * Create queue2, publish 1 message to it > Running a consuming application (AMQPNetLite) connecting to node2 of the > cluster: > * On node1 of the cluster, queue1 & queue2 now have 0 messages in it > * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 > messages in it (i.e. an additional message in each queue, even though the > consuming application is not publishing any messages). > * The consuming application connected to node2 of the cluster does not > consume any messages off either queue1 or queue2 from node2 (of the cluster). > In artemis.log on node2 of the cluster, the following error appears: > 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] > AMQ222151: removing consumer which did not handle a message, > consumer=ServerConsumerImpl > Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1928) Messages in queues on other nodes in a cluster are not consumable
Simon Chalmers created ARTEMIS-1928: --- Summary: Messages in queues on other nodes in a cluster are not consumable Key: ARTEMIS-1928 URL: https://issues.apache.org/jira/browse/ARTEMIS-1928 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP, Broker Affects Versions: 2.6.1 Environment: * Broker Version: 2.6.1 * Client: AMQPNetLite v2.1.2 * Host OS: Linux node 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux * Host Platform: AWS EC2 * broker.xml from node1 attached as node1-broker.xml * broker.xml from node2 attaches as node2-broker.xml Reporter: Simon Chalmers Steps to produce, using a producing application (running AMQPNetLite) connecting to node1 of the cluster: * Create queue1, publish 199 messages to it * Create queue2, publish 1 message to it Running a consuming application (AMQPNetLite) connecting to node2 of the cluster: * On node1 of the cluster, queue1 & queue2 now have 0 messages in it * On node2 of the cluster, queue1 has 200 messages in it and queue2 has 2 messages in it (i.e. an additional message in each queue, even though the consuming application is not publishing any messages). * The consuming application connected to node2 of the cluster does not consume any messages off either queue1 or queue2 from node2 (of the cluster). In artemis.log on node2 of the cluster, the following error appears: 2018-06-13 02:41:00,604 WARN [org.apache.activemq.artemis.core.server] AMQ222151: removing consumer which did not handle a message, consumer=ServerConsumerImpl Full log @ [https://pastebin.com/N0Jdr0Ha] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ARTEMIS-1709) Can't send large messages with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers resolved ARTEMIS-1709. - Resolution: Fixed Fix Version/s: 2.5.0 Using 2.5.0 appears to have fixed the issue; closing this off for now. Thanks for the help! > Can't send large messages with AMQP > --- > > Key: ARTEMIS-1709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.4.0 > Environment: broker.xml file attached. >Reporter: Simon Chalmers >Priority: Major > Fix For: 2.5.0 > > Attachments: broker.xml > > > Sending a single message using AMQP to a queue where the size of the single > message is 501741 bytes errors out. > Sending the same single message to version 2.3.0 of Artemis does not result > in the same error and is sent successfully. > Error: > > Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on > the Server''s Session > at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in > C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390503#comment-16390503 ] Simon Chalmers commented on ARTEMIS-1709: - Great, thanks! Confirmed with our simple test that it passes and the large message is now sent. We'll run some more tests over the next short while and see how it goes before updating this JIRA further. > Can't send large messages with AMQP > --- > > Key: ARTEMIS-1709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.4.0 > Environment: broker.xml file attached. >Reporter: Simon Chalmers >Priority: Major > Attachments: broker.xml > > > Sending a single message using AMQP to a queue where the size of the single > message is 501741 bytes errors out. > Sending the same single message to version 2.3.0 of Artemis does not result > in the same error and is sent successfully. > Error: > > Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on > the Server''s Session > at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in > C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16389100#comment-16389100 ] Simon Chalmers commented on ARTEMIS-1709: - The mvn install command completed successfully but I'm a bit lost/confused as to what to do next, apologies for that. Where/what do I get access to the artemis binaries/package to then fire up the server? > Can't send large messages with AMQP > --- > > Key: ARTEMIS-1709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.4.0 > Environment: broker.xml file attached. >Reporter: Simon Chalmers >Priority: Major > Attachments: broker.xml > > > Sending a single message using AMQP to a queue where the size of the single > message is 501741 bytes errors out. > Sending the same single message to version 2.3.0 of Artemis does not result > in the same error and is sent successfully. > Error: > > Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on > the Server''s Session > at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in > C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at > System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task > task) > at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379819#comment-16379819
]
Simon Chalmers edited comment on ARTEMIS-1709 at 2/28/18 6:07 AM:
--
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
wait senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
was (Author: auskeptic):
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379819#comment-16379819
]
Simon Chalmers edited comment on ARTEMIS-1709 at 2/28/18 6:06 AM:
--
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[60];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
was (Author: auskeptic):
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[6];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ARTEMIS-1709) Can't send large messages with AMQP
[
https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16379819#comment-16379819
]
Simon Chalmers commented on ARTEMIS-1709:
-
Example tester client code, using Amqp.Net Lite.
var connectionFactory = new ConnectionFactory();
var connection = await connectionFactory.CreateAsync(new
Address("amqp://artemis:simetraehcapa@linuxhost"));
var session = new Session(connection);
var senderLink = new SenderLink(session, "sender-link",
"queue.in.my-service.test-request");
var rng = new Random();
var messageContent = new byte[6];
rng.NextBytes(messageContent);
senderLink.Send(new Message(messageContent));
await senderLink.CloseAsync();
await session.CloseAsync();
await connection.CloseAsync();
> Can't send large messages with AMQP
> ---
>
> Key: ARTEMIS-1709
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1709
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
>Affects Versions: 2.4.0
> Environment: broker.xml file attached.
>Reporter: Simon Chalmers
>Priority: Major
> Fix For: 2.3.0
>
> Attachments: broker.xml
>
>
> Sending a single message using AMQP to a queue where the size of the single
> message is 501741 bytes errors out.
> Sending the same single message to version 2.3.0 of Artemis does not result
> in the same error and is sent successfully.
> Error:
>
> Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on
> the Server''s Session
> at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds)
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext()
> in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in
> C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging
> Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131
> — End of stack trace from previous location where exception was thrown —
> at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
> at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
> task)
> at MI.Messaging.AmqpNetLite.Test.Program.(String[] args)
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ARTEMIS-1709) Can't send large messages with AMQP
[ https://issues.apache.org/jira/browse/ARTEMIS-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Chalmers updated ARTEMIS-1709: Description: Sending a single message using AMQP to a queue where the size of the single message is 501741 bytes errors out. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 — End of stack trace from previous location where exception was thrown — at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) was: Sending a single message using AMQP to a queue of mesage size 501741 bytes errors. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) > Can't send large messages with AMQP > --- > > Key: ARTEMIS-1709 > URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 > Project: ActiveMQ Artemis > Issue Type: Bug > Components: AMQP >Affects Versions: 2.4.0 > Environment: broker.xml file attached. >Reporter: Simon Chalmers >Priority: Major > Fix For: 2.3.0 > > Attachments: broker.xml > > > Sending a single message using AMQP to a queue where the size of the single > message is 501741 bytes errors out. > Sending the same single message to version 2.3.0 of Artemis does not result > in the same error and is sent successfully. > Error: > > Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on > the Server''s Session > at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) > at > MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() > in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging > Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 > — End of stack trace from previous location where exception was thrown — > at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() > at >
[jira] [Created] (ARTEMIS-1709) Can't send large messages with AMQP
Simon Chalmers created ARTEMIS-1709: --- Summary: Can't send large messages with AMQP Key: ARTEMIS-1709 URL: https://issues.apache.org/jira/browse/ARTEMIS-1709 Project: ActiveMQ Artemis Issue Type: Bug Components: AMQP Affects Versions: 2.4.0 Environment: broker.xml file attached. Reporter: Simon Chalmers Fix For: 2.3.0 Attachments: broker.xml Sending a single message using AMQP to a queue of mesage size 501741 bytes errors. Sending the same single message to version 2.3.0 of Artemis does not result in the same error and is sent successfully. Error: Unhandled Exception: Amqp.AmqpException: AMQ119029: No address configured on the Server''s Session at Amqp.SenderLink.SendInternal(Message message, Int32 waitMilliseconds) at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 54 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at MI.Messaging.AmqpNetLite.Test.MessageDispatcher.d__6.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\MessageDispatcher.cs:line 102 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.d__17.MoveNext() in C:\Users\BillPoole\Documents\Visual Studio 2017\Projects\MI Messaging Framework\MI.Messaging.AmqpNetLite.Test\Program.cs:line 131 --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at MI.Messaging.AmqpNetLite.Test.Program.(String[] args) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ARTEMIS-1708) Missing documentation on queue attributes
Simon Chalmers created ARTEMIS-1708: --- Summary: Missing documentation on queue attributes Key: ARTEMIS-1708 URL: https://issues.apache.org/jira/browse/ARTEMIS-1708 Project: ActiveMQ Artemis Issue Type: Improvement Affects Versions: 2.4.0, 2.3.0 Reporter: Simon Chalmers Queue Attributes documentation is blank for 2.3.0 / latest: [https://activemq.apache.org/artemis/docs/latest/queue-attributes.html] Should be similar to 1.5.5, I imagine: [https://activemq.apache.org/artemis/docs/1.5.5/queue-attributes.html] Same result in Google Chrome, Edge, so not a browser related display issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
