WebSocket API仅返回Azure API管理上的HTTP 429
我们有一个使用MQTTNET库发布的WebSocket上的Web应用程序，该应用程序在WebSocket上使用了自己的MQTT主题。最重要的是，我们在Azure API管理中定义了一个Websocket API。直到2022-06-06，这一直效果很好。突然，所有Websocket请求都被APIM的HTTP 429“太多请求”拒绝。 APIM甚至没有尝试联系服务。
如果有沉重的负担，我本可以理解这一点，但是我们只有来自公司内部的少数应用程序用户，因此我们远离了Documumantation所描述的200个用户的限制。该应用程序会在几秒钟内进行几次（5-10）的重新连接尝试。 MQTT服务和APIM API已进行了重建，以删除任何悬挂会议，但没有帮助。
有人遇到类似问题吗？ APIM团队是否可以改变任何内部逻辑，突然开始触发HTTP 429响应？
We have a web application consuming our own MQTT topic over websocket, published using the MQTTnet library. On top of this, we have defined a Websocket API in Azure API Management. This has worked fine until 2022-06-06. Suddenly, all websocket requests are rejected with a http 429 'Too Many Requests' from APIM. The APIM doesn't even try to contact the service.
I could have understood this if there was a heavy load, but we only have a handful of application users from within the company, so we are far from the 200 users limit that ther documantation describes. The application sneds a few (5-10) reconnection attempts within a few seconds. The MQTT service and the APIM API have been rebuilt in order to remove any hanging sessions, but to no help.
Has anyone run into similar problems? Could the APIM team have changed any internal logic that suddenly started trigging the http 429 responses?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我已经开始在同一时间遇到完全相同的问题（以前从未见过）。我对Azure支持的理解是，文档是错误的。每个服务单元是100个活动Websocket连接。似乎在关闭WebSocket时，积极的计数也不会像预期的那样减少。
Azure缺乏对什么是Active Websocket会话的观察性，并得到了Azure支持的认可。通常，我需要等待1-2天，直到我的申请再次打开Websocket之前，我需要等待1-2天。
编辑MS在此处确认了一个错误，并在10月发布的APIM发行中发布了一个修复程序 - https://github.com/azure/api-management/releases/tag/release-service-2022-10
I have started to experience the exact same issue around the same time (having never seen it before). My understanding from speaking to azure support on this is that the docs are wrong. It is 100 active websocket connections per service unit. It also seems that the active count is not reduced as expected when websockets are closed.
The observability on what is an active websocket session is very much lacking in azure and was acknowledged by azure support. I typically need to wait 1-2 days after the limit is breached before my application can open websockets again.
EDIT MS Acknowledged a bug here and have released a fix in their October release of APIM - https://github.com/Azure/API-Management/releases/tag/release-service-2022-10