mbrusamolin
commented
6 years ago Just discovered that a very similar issue affects outgoingWindow: this variable is constantly drained and this process leads to an unreadable queue/topic.
E.g.: 36|core-sc | Thu, 19 Oct 2017 14:01:49 GMT amqp10:framing => @flow(19) [nextIncomingId=711 incomingWindow=97 nextOutgoingId=1 outgoingWindow=100 handle=0 deliveryCount=711 linkCredit=1 available=0 drain=false echo=false properties={}] 36|core-sc | Thu, 19 Oct 2017 14:01:49 GMT amqp10:framing <= @flow(19) [nextIncomingId=1 incomingWindow=5000 nextOutgoingId=726 outgoingWindow=82 handle=null deliveryCount=null linkCredit=null available=null drain=false echo=true properties={}] [...] 36|core-sc | Thu, 19 Oct 2017 14:09:43 GMT amqp10:framing => @flow(19) [nextIncomingId=4429 incomingWindow=96 nextOutgoingId=1 outgoingWindow=100 handle=0 deliveryCount=4429 linkCredit=1 available=0 drain=false echo=false properties={}] 36|core-sc | Thu, 19 Oct 2017 14:09:47 GMT amqp10:framing <= @flow(19) [nextIncomingId=1 incomingWindow=5000 nextOutgoingId=4525 outgoingWindow=0 handle=null deliveryCount=null linkCredit=null available=null drain=false echo=true properties={}] 36|core-sc | Thu, 19 Oct 2017 14:09:47 GMT amqp10:session New Incoming Window (known id): 5000 = 1 + 5000 - 1 36|core-sc | Thu, 19 Oct 2017 14:11:32 GMT amqp10:framing <= (EMPTY FRAME) 36|core-sc | Thu, 19 Oct 2017 14:11:48 GMT amqp10:framing => (EMPTY FRAME) 36|core-sc | Thu, 19 Oct 2017 14:12:47 GMT amqp10:framing <= @flow(19) [nextIncomingId=1 incomingWindow=5000 nextOutgoingId=4525 outgoingWindow=0 handle=null deliveryCount=null linkCredit=null available=null drain=false echo=true properties={}] 36|core-sc | Thu, 19 Oct 2017 14:12:47 GMT amqp10:session New Incoming Window (known id): 5000 = 1 + 5000 - 1 36|core-sc | Thu, 19 Oct 2017 14:13:48 GMT amqp10:framing => (EMPTY FRAME) 36|core-sc | Thu, 19 Oct 2017 14:14:32 GMT amqp10:framing <= (EMPTY FRAME)
Hi, we had incurred in a problem related to the incomingWindow value. Our platform handles messages that are up to 700k with Azure Service Bus thus using more than 1 window per single message.
Upon the "receiver.accept", using AMQP.Policy.Utils.RenewOnSettle(1, 1, AMQP.Policy.ServiceBusTopic), a single credit is correctly (re)gained, but only 1 frame is added to incomingWindow.
This cause a progressive drain of incomingWindow amount and when it reaches half of its capacity "WindowPolicies" "RefreshAtHalf" is triggered and "session.addWindow" is called.
Unfortunately this last method has some issues resulting in a null value of "receiver_link.js" "transferFrame.deliveryId" and maybe other misconfigurations. E.g.: after the addWindow call with a defaultIncomingWindow of 100 debug reports: amqp10:link:receiver Rx message null on scorm/Subscriptions/scorm_8f279293-3d42-4cf1-b585-70731dc65c19, 0 credit, 50 window left.
At this point the receiver stops reading the queue/topic.
With a quick&dirty patch in our code that restores the incomingWindow to 100 after every accept the problem seems bypassed. Actually we are pretty busy but we can support you at our best if needed.