Details
-
Bug
-
Resolution: Done
-
Major
-
A-MQ 7.0.0.ER12
-
None
-
None
Description
This error originally reported as a client bug. See
https://issues.jboss.org/browse/ENTMQCL-433?focusedCommentId=13345021&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13345021
I've reproduced my comment here. Essentially the expected broker behavior is:
client sends: attach(receive link with bogus filter) broker sends: attach(receive link) broker sends: detach(receive link, error-with-condition)
The broker should detach immediately upon seeing the error and not defer reporting the error until the client closes the link.
---- cut from ENTMQCL-433 ----
This seems more of a broker bug than a client bug.
I ran this test against broker
https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?product=jboss.amq&downloadType=distributions
"7.0.0", "Beta1"
and get essentially the same result. I added some extra log statements to the console output:
[04:08.401] SEND AMQP 0 1.0.0 [04:08.401] SEND (ch=0) open(container-id:61d1b57f-463d-48fc-bcb7-373ea7ef7806,host-name:10.10.55.152,max-frame-size:262144,channel-max:256) [04:08.416] SEND (ch=0) begin(next-outgoing-id:4294967293,incoming-window:2048,outgoing-window:2048,handle-max:4294967295) ===== Creating receiver [04:08.416] SEND (ch=0) attach(name:receiver-Selectors,handle:0,role:True,source:source(address:jms.queue.test,filter:[filter1:foo/bar]),target:target()) ===== Creating sender [04:08.416] SEND (ch=0) attach(name:sender-Selectors,handle:1,role:False,source:source(),target:target(address:jms.queue.test),initial-delivery-count:0) ===== Sending messages [04:08.463] RECV AMQP 0 1 0 0 [04:08.479] RECV (ch=0) open(container-id:0.0.0.0,host-name:,max-frame-size:4294967295,channel-max:65535,idle-time-out:30000,offered-capabilities:[sole-connection-for-container,DELAYED_DELIVERY],properties:[product:apache-activemq-artemis,version:1.3.0.amq-700005-redhat-1]) [04:08.479] RECV (ch=0) begin(remote-channel:0,next-outgoing-id:1,incoming-window:2147483647,outgoing-window:2147483647,handle-max:65535) [04:28.495] RECV (ch=0) attach(name:receiver-Selectors,handle:0,role:False,snd-settle-mode:2,rcv-settle-mode:0,source:source(address:jms.queue.test,durable:0,expiry-policy:session-end,timeout:0,dynamic:False,filter:[filter1:foo/bar]),target:target(),incomplete-unsettled:False,initial-delivery-count:0) [04:28.495] RECV (ch=0) attach(name:sender-Selectors,handle:1,role:True,snd-settle-mode:2,rcv-settle-mode:0,source:source(),target:target(address:jms.queue.test)) [04:28.495] RECV (ch=0) flow(next-in-id:4294967293,in-window:2147483647,next-out-id:1,out-window:2147483647,handle:1,delivery-count:0,link-credit:100) [04:28.495] SEND (ch=0) transfer(handle:1,delivery-id:0,delivery-tag:00000000,message-format:0,settled:False,batchable:True) payload 55 [04:28.573] RECV (ch=0) disposition(role:True,first:0,last:0,settled:True,state:accepted()) [04:28.573] SEND (ch=0) transfer(handle:1,delivery-id:1,delivery-tag:00000001,message-format:0,settled:False,batchable:True) payload 55 [04:28.635] RECV (ch=0) disposition(role:True,first:1,last:1,settled:True,state:accepted()) ===== Receiving messages [04:28.635] SEND (ch=0) flow(next-in-id:1,in-window:2048,next-out-id:4294967295,out-window:2147483645,handle:0,delivery-count:0,link-credit:200,drain:False) [04:29.651] SEND (ch=0) detach(handle:1,closed:True) [04:29.713] RECV (ch=0) detach(handle:1,closed:True) [04:29.713] SEND (ch=0) detach(handle:0,closed:True) [04:35.495] SEND (ch=0) empty [04:39.776] RECV (ch=0) detach(handle:0,closed:True,error:error(condition:amqp:invalid-field,description:foo/bar)) [04:39.776] SEND (ch=0) end() [04:39.838] RECV (ch=0) end() [04:39.838] SEND (ch=0) close() [04:39.901] RECV (ch=0) close()
Following along I see:
1. The client pipes (AMQP, open, begin, attach, attach) to create the receiver and sender. It's even in the send loop waiting for credits on the send link to make progress.
2. The broker returns (AMQP, open, begin). Then there's a 20 second delay returning the (attach attach, flow). I don't understand this pause.
3. The client transfers two messages and receives accepted dispositions and another flow.
4. At time 04:29.651 the client gives up waiting for received messages and closes the sender and receiver. The broker sends an error in the receiver detach response at 04:39.776.
I suppose that the original complaint in this issue is that the client does not throw an exception on receiving the detach-with-error. However, the client closed the link first and is already tearing the link down. Errors at this point in the link life cycle are not that meaningful.
More troublesome is that the broker did not send the detach immediately after the attach(name:receiver-Selector) frame. The broker did not send the detach-with-error until after the client closed the link.
