You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Just discovered that a very similar issue affects outgoingWindow: this variable is constantly drained and this process leads to an unreadable queue/topic.
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.
The text was updated successfully, but these errors were encountered: