试图重新连接的大火 - 使用Web Assembly，还是...？
我被恐惧的“试图重新连接”信息困扰。该问题仅在应用程序在Azure上发布时发生，而在本地运行时绝不会发生。该问题是通过显示对话（同步）和等待来复制的。对话具有许多标准编辑控件。您会在3-8分钟后看到重新连接消息，然后出现403个错误，并带有浏览器控制台MSG“ Websocket使用状态代码：1006”。这是服务器端应用程序.NET 5.0，X86，vs 2019。
我对某些第三方组件有我的怀疑，但担心这个问题始终会拐弯。在显示同步对话框时，最常看到它。我正在尝试消除问题，以揭露问题的根本原因，而迄今为止没有可重复的成功。
目前，这个高度令人沮丧且耗时的问题正在阻止所有进步和部署，幽灵必须完全替换所有组件或进行一些重大的重写。到目前为止，融合无法再现问题，但是在混合中有数十亿个变量，这并不奇怪。
在这种情况下，错误1006的可能原因是什么？我如何调试任何东西以找到真正的罪魁祸首？
如何通过一些静脉型消息来防止整个问题？
我如何完全控制超时期，例如将超时扩展到15分钟？看来用户需要时间进行这种复杂的对话/表单 - 这可能是根本不使用对话的理由...
是否会从服务器端转到Web组装消除/避免问题？
在某些绝望中，谢谢。
I am being plagued with the dreaded "Attempting to reconnect" message. The problem only occurs when the application is published on Azure, never when run locally. The problem is reproduced by showing a dialogue (Syncfusion) and waiting. The dialogue has a number of standard edit controls. You see the reconnect message after around 3-8 mins and then a 403 error, with the browser console msg "WebSocket closed with status code: 1006". This is a server-side application .Net 5.0, x86, VS 2019.
I have my suspicions about some third-party components but fear that this problem will always be round the corner. It is most frequently seen when displaying a Syncfusion dialog. I am trying, by elimination, to expose the root cause of the problem, without repeatable success so far.
At the moment, this highly frustrating and time-consuming problem is blocking all progress and deployment, with the spectre of having to completely replace all components or do some major re-write. Syncfusion, so far, can not reproduce the issue, but with a zillion variables in the mix, this is not surprising.
What are the likely causes of error 1006 in this context and how might I debug anything to find the real culprit?
How can I prevent this entire issue e.g. with some keep-alive type message?
How can I completely control the timeout period e.g. extend the timeout to 15+ mins? Seemingly users need time on this complex dialogue/form - which might be a justification for not using a dialogue at all...
Would switching from server-side to web assembly eliminate/avoid the problem?
In some desperation, thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
@henkholterman Web插座在Azure配置中为“ ON”。
向所有人道歉 - 我现在找到了根本原因。这全都是由于“共享CPU” Azure Plan（D1）引起了CPU重新启动/重置某种形式的效果。我能够将视图更改与Azure的配额视图相关联。当您考虑一下时，很明显，但我并不了解所使用的计划，并且可能会想象一些魔术会阻止这种丑陋的效果。似乎没有现实的选择，只能移至至少B1或更高。 @Jessegood-感谢您的伐木线索 - 这使我迈进了这一结果。
@HenkHolterman Web Sockets are "On" in the Azure config.
Apologies to all - I have now found the root cause. It was all due to the "shared CPU" Azure plan (D1) which caused a CPU restart/reset of some sort, which had the effect described. I was able to correlate the view change with the quota view in Azure. Obvious when you think about it, but I was not that aware of the plan used and might have imagined that some magic would have prevented this ugly effect. Seems there is no realistic alternative but to move to at least B1 or above. @JesseGood - thanks for the logging leads - that led me towards this result.