<div dir="ltr">We've seen this too. We use sticky sessions (using a cookie) as a workaround, like David suggested.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 29, 2013 at 8:51 AM, Malthe Borch <span dir="ltr"><<a href="mailto:mborch@gmail.com" target="_blank">mborch@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It sounds like a race condition. It might be that you've got a very<br>
low network latency between the web server and web browser such that<br>
there's hardly any time for the invalidation messages to propagate.<br>
<br>
But just to be certain it's not an issue with system time, check if<br>
your entire cluster is time-synchronized.<br>
<br>
\malthe<br>
<div><div class="h5"><br>
On 29 May 2013 08:42, David Glick (Plone) <<a href="mailto:david.glick@plone.org">david.glick@plone.org</a>> wrote:<br>
> On 5/28/13 7:53 PM, Dylan Jay wrote:<br>
><br>
> Hi,<br>
><br>
> My colleague is having the issue outlined below. I thought this list might<br>
> be better to give an insight as to what is going on?<br>
><br>
> Begin forwarded message:<br>
><br>
> From: Adam Terrey <<a href="mailto:adam@pretaweb.com">adam@pretaweb.com</a>><br>
> Subject: Fwd: Zope/Plone/Zeo Concurrency Issue<br>
> Date: 28 May 2013 5:23:33 PM AEST<br>
> To: Dylan Jay <<a href="mailto:djay@pretaweb.com">djay@pretaweb.com</a>><br>
><br>
><br>
><br>
><br>
> -------- Original Message --------<br>
> Subject: Zope/Plone/Zeo Concurrency Issue<br>
> Date: Tue, 28 May 2013 16:04:21 +1000<br>
> From: Adam Terrey <<a href="mailto:adam@pretaweb.com">adam@pretaweb.com</a>><br>
> To: <a href="mailto:Zope@zope.org">Zope@zope.org</a><br>
><br>
><br>
> Hi,<br>
><br>
> Can someone offer some insight into what might be going on here and perhaps<br>
> how I can debug the following issue?<br>
><br>
> In Plone there is a request patten used to create content which looks<br>
> like...<br>
><br>
> (A) GET request to /MySite/createObject?type_name=Document<br>
> Responds with a redirect to a tempory document at a location such as<br>
> /MySite/portal_factory/Document/document.2013-05-28.1878040976/edit<br>
> (B) GET /MySite/portal_factory/Document/document.2013-05-28.1878040976/edit<br>
> Responds with from to set fields in the Document<br>
> (C) POST request to<br>
> /MySite/portal_factory/Document/document.2013-05-28.1878040976/atct_edit<br>
> Responds with a redirect to the final location of the document such as<br>
> /Mysite/my-page<br>
> (D) GET /Mysite/my-page<br>
> Responds with the newly created page<br>
><br>
> In one of our production systems we are running multiple Zope/Plone<br>
> instances connecting to a Zeo server. And the above patten works about 95%<br>
> of the time. However, sometimes request (D) will respond with 404 Page Not<br>
> Found. My assumptions is that request (C) and (D) are going to different<br>
> instances and somehow the instance handling request (D) does not yet see the<br>
> transaction with completed the page creation.<br>
><br>
> I've checked that the transaction commit happens before response headers are<br>
> emitted for request (C) - suspecting the case that the browser handles the<br>
> redirect before the transaction is completed - but this is clearly not the<br>
> case from what i can see. The transaction is well committed before response<br>
> headers are returned.<br>
><br>
> Versions are as follows:<br>
><br>
> Plone 4.1.3 (4112)<br>
> CMF 2.2.4<br>
> Zope 2.13.10<br>
> Python 2.7.2+ (default, Oct 4 2011, 20:06:09) [GCC 4.6.1]<br>
><br>
> I have been using the following script to recreate the issue. I seem to be<br>
> able to produce the error quicker if I put server2 under apache-bench load,<br>
> and I have been able to recreate the issue on a local copy of our production<br>
> system but it is a far more rare case.<br>
><br>
> auth = ('admin', 'admin')<br>
> server1 = '<a href="http://localhost:46101" target="_blank">http://localhost:46101</a>'<br>
> server2 = '<a href="http://localhost:46102" target="_blank">http://localhost:46102</a>'<br>
> site = '/Plone'<br>
><br>
> import requests<br>
><br>
> ses = requests.Session()<br>
> ses.auth=auth<br>
><br>
> for i in range(10):<br>
><br>
> # Create tempory Object<br>
> create_url = server1 + site + '/createObject?type_name=Document'<br>
> print "GET", create_url<br>
> res = ses.get (create_url)<br>
> tempory_obj = res.url.rsplit("/", 1)[0]<br>
> print "tempory object:", tempory_obj<br>
><br>
><br>
> # Submit data to create object (response will<br>
> # be the redirect ot the ojbect's location)<br>
><br>
> data = {<br>
> 'id': '',<br>
> 'title': 'page' + str(i) ,<br>
> 'form.button.save': 'Save',<br>
> 'form.submitted': '1',<br>
> "description": "some secriot",<br>
> "text": "some text"<br>
> }<br>
><br>
> post_url = tempory_obj + "/atct_edit"<br>
> print "POST", post_url<br>
> res = ses.post(post_url, data=data, allow_redirects=False)<br>
><br>
> redirect_location = "/" + res.headers['location'][7:].split('/',1)[1]<br>
> print 'redirect_location', redirect_location<br>
><br>
><br>
> # Request object from the redirect from server2<br>
> redirect_url = server2 + redirect_location<br>
> print "GET", redirect_url<br>
> res = ses.get(redirect_url)<br>
><br>
> if res.status_code != 200:<br>
> last404 = res<br>
> print res;<br>
> break;<br>
><br>
> print "---"<br>
><br>
><br>
> Any help would be appreciated.<br>
><br>
><br>
> I've encountered a problem like this once or twice and had some trouble<br>
> reproducing it consistently, but assume it's due to ZEO invalidation<br>
> messages not making it to the other instance before it serves request D.<br>
><br>
> You can work around the issue using sticky sessions in your load balancer.<br>
> If you don't want users to be stuck to a particular backend indefinitely you<br>
> can set a cookie with a brief expiration in an ObjectAddedEvent handler and<br>
> use it as the basis for the stickiness.<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> For more information about ZODB, see <a href="http://zodb.org/" target="_blank">http://zodb.org/</a><br>
><br>
> ZODB-Dev mailing list - <a href="mailto:ZODB-Dev@zope.org">ZODB-Dev@zope.org</a><br>
> <a href="https://mail.zope.org/mailman/listinfo/zodb-dev" target="_blank">https://mail.zope.org/mailman/listinfo/zodb-dev</a><br>
><br>
<br>
<br>
<br>
--<br>
Au revoir, et tous mes voeux pour un avenir plein de succès et de bonheur ––<br>
<br>
Malthe Borch<br>
<a href="mailto:mborch@gmail.com">mborch@gmail.com</a><br>
_______________________________________________<br>
For more information about ZODB, see <a href="http://zodb.org/" target="_blank">http://zodb.org/</a><br>
<br>
ZODB-Dev mailing list - <a href="mailto:ZODB-Dev@zope.org">ZODB-Dev@zope.org</a><br>
<a href="https://mail.zope.org/mailman/listinfo/zodb-dev" target="_blank">https://mail.zope.org/mailman/listinfo/zodb-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Roel Bruggink<br><a href="http://www.fourdigits.nl/mensen/roel-bruggink" target="_blank">http://www.fourdigits.nl/mensen/roel-bruggink</a><br><br><font face="arial, sans-serif"><span style="border-collapse:collapse">Four Digits BV</span></font><br>
<a href="http://www.fourdigits.nl/" target="_blank">http://www.fourdigits.nl</a><span> </span><span>tel: <a value="+31264422700" style="color:rgb(17,85,204)">+31(0)26 4422700</a></span>
</div>