Plone yields 404 on new content save

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?

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:

1. Verfy that the content object was, indeed, created.
2. Check that the content views are correct (the ones that are declared in profiles/default/types/yourtype.xml).
3. Does it happen when adding content directly to plone instance (Without caching and load balancing?
4. Does it happen when adding content to direct plone instance with load balancing, but without caching? ---> And so on ...?
5. Maybe not an elegant one, but you might try inserting print statements or pdb breakpoints in the code so you can track whenever a content object was, indeed, created. Do this only as a desperate method of "instrumentation".

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.