Plone 在保存新内容时生成 404
问题:内容编辑器保存新内容项,并在新对象的正确 URL 上获取 404。如果它们随后刷新,则该项目就在那里,完全正常。
这种情况发生在多种基于原型的内容类型上,并且我们至少在两个不同的网站上看到过这种情况。我们已经在 Plone 3.x 和 4.0.3 上看到过它。以下是这些站点的共同点:
- HAProxy 负载平衡(有或没有会话关联)
- 多个 ZEO 客户端
- 使用 ZODB 3.9.7 或 3.8.4
- 该问题仅在某些时候发生,可能是四分之一的内容项
有人知道吗见过这样的东西吗?
The issue: a content editor saves a new content item and gets a 404 on the proper-looking url for the new object. If they then refresh, the item is there, perfectly normal.
This happens for multiple Archetypes-based content types, and we've seen it on at least two different sites. We've seen it on Plone 3.x and 4.0.3. Here's what these sites have in common:
- HAProxy load balancing (with and without session affinity)
- Multiple ZEO clients
- Using either ZODB 3.9.7 or 3.8.4
- The issue happens only some of the time, maybe for 1 out of 4 content items
Has anyone seen anything like this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我没有办法给你答案;这实际上不应该发生。我当然没有见过这个。
您需要收集更多信息来解决此问题,这可能需要与专家进行交互访问,而 SO 不适合进行此类故障排除。
我所能做的就是建议您收集尽可能多的信息,包括来自各种日志(包括 HAProxy 和 ZEO 服务器)的用户交互的完整跟踪。
它可能需要在服务器级别进行额外的检测(当发生 NotFound 错误时,转储有关存在内容的附加信息等)。
I do not have an answer for you; this should not really happen. I certainly have not seen this.
You'll need to gather more information to troubleshoot this, and that perhaps requires interactive access to experts, and SO is not the place for such troubleshooting.
All I can do is advice that you gather as much information as possible, including a full trail of the user interaction from the various logs, including HAProxy and the ZEO server.
It may require additional instrumentation at the server level (when the NotFound error occurs, dump additional information about what is present, etc).
一些建议/问题:
Some recomendations/questions:
是的。我们最近开始看到同样的问题。我们有几乎相同的设置。 Haproxy(无会话关联)。
我想知道,因为该模式似乎是 haproxy...也许是超时后重新分发请求的问题?
更新:
我们遇到了这个问题。当您在保存后重定向回已更改的对象时,就会发生这种情况。这是因为第二个请求到达了另一个 zeo 客户端,该客户端没有意识到它已经过时。
我们找到的唯一解决方案是在任何 POST 期间在 haproxy 中添加临时会话关联(20 秒)。不理想但确实有效。我只是在寻找更好的解决方案,这就是我找到这篇旧帖子的原因。
Yes. we have recently started seeing the same issue. We have almost the same setup. Haproxy (no session affinity).
I'm wondering since the pattern seems to be haproxy... perhaps its an issue with a request being redistributed after a timeout?
Updated:
We had this issue. It happens when you have a redirect back to the changed object after a save. This is because the 2nd request hits another zeo client which doesn't realise it's out of date.
The only solution we found was a to add temporary session affinity in haproxy (20s) during any POST. Not ideal but does work. I was just searching for a better solution which is why I found this old post.