#105 — ConflictErrors on concurrent writes

State	Resolved
Version:	1.1
Area	Functionality
Issue type	Bug
Severity	Medium
Submitted by	Benjamin Liles
Submitted on	Oct 29, 2007
Responsible	Ricardo Newbery
Target release:	1.1.1

Return to tracker

Last modified on Jan 08, 2009 by Matthew Wilkes

We are running CacheFu behind varnish and noticed quite a few ConflictErrors in the CacheTool when multiple people were trying to write to their own profiles. This was different people writing to different parts of the site, but it appears that they were all trying to write to the CacheTool.

Steps to reproduce:: Multiple Zope instances
Multiple users
Edit multiple pages simultaneously

Attached:

extract.log — application log, 27Kb

Added byBenjamin LilesonOct 29, 2007 10:06 PM

Target release: 1.1.1 → None

Responsible manager: newbery → (UNASSIGNED)

This also happens when multiple people are editing with only 1 Zope instance

Added byRicardo NewberyonOct 29, 2007 10:48 PM

Issue state: unconfirmed → open

Responsible manager: (UNASSIGNED) → newbery

Thanks for the report. I'm not surprised by the conflict errors. I would be more concerned if they were unresolved conflict errors.

Upon content edit, a freshness variable is incremented on the cachetool. If several folks are submitting simultaneous edits, then conflicts during this increment process are bound to happen. Perhaps it makes sense to make this a non-persistent variable. Unless we hear of unresolved conflicts, this may be a low priority improvement.

I'm leaving this ticket open so I don't forget this.

Added by(anonymous)onOct 30, 2007 04:36 PM

The problem is that despite the fact that there are no unresolved conflicts, after rolling back transactions 3 times, it displays and error to the users. With as many conflicts as it creates with a moderate load (4 users), at least one person would repeatedly receive an error page. I am currently trying to catch ConflictErrors that are raised when incrementing the counters.

Added byBenjamin LilesonOct 30, 2007 04:43 PM

Adding a single page increments the permission counter more than 200 and the catalog counter by over 100. There must be a better way of doing this.

Added byRicardo NewberyonOct 30, 2007 09:08 PM

Sounds like something is wrong in your installation. Last time I checked, it only increments by 2. I'll recheck on a development instance when I get the chance.

Also, it seems odd that the resolved conflict errors are being shown to your users. I don't think it's supposed to do that. But if you're incrementing 200+ times with every edit, I suspect that some conflict errors are not being resolved.

Added bypierre gayvalletonJan 31, 2008 05:50 PM

I'm actually stress testing a plone (3.0.5) site for a client, and I'm having the same conflictErrors problem. It's on a ZEO architecture ( apache - squid - pound - 6 zeo clients - zeo server)
I'm simulating high site traffic, and after a certain amound ( around 50 contributors at the same time ) the conflictsErrors DO GO unresolved, and users get beautiful Zope conflictError tracebacks.
I checked the number of catalog counter increment per edit - 6 in my case.
Volatile counter is not a solution, due to ZEO architecture, but actual way is not either.
There must be something...

Added bypierre gayvalletonJan 31, 2008 05:51 PM

Added byRicardo NewberyonFeb 06, 2008 03:21 AM

Issue state: open → in-progress

Found a potential source for the unresolved conflicts. Fixed in svn... http://dev.plone.org/collective/changeset/58318

Let me know if this fixes your usecase so I can close this ticket.

Added bypierre gayvalletonFeb 27, 2008 05:04 PM

Yes, this actually fix the problem. No more conflictError on the tool class during transactions.
Thanks

Added byRicardo NewberyonApr 04, 2008 01:06 AM

Issue state: in-progress → resolved

Target release: None → 1.1.1

Fixed in 1.1.1

No responses can be added.