#105 — ConflictErrors on concurrent writes
by
Benjamin Liles
—
last modified
Jan 08, 2009 01:59 PM
| 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 |
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
Added by
Benjamin Liles
on
Oct 29, 2007 10:06 PM
This also happens when multiple people are editing with only 1 Zope instance
Target release:
1.1.1
→
None
Responsible manager:
newbery
→
(UNASSIGNED)
Added by
Ricardo Newbery
on
Oct 29, 2007 10:48 PM
Thanks for the report. I'm not surprised by the conflict errors. I would be more concerned if they were unresolved conflict errors.
Issue state:
unconfirmed
→
open
Responsible manager:
(UNASSIGNED)
→
newbery
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)
on
Oct 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 by
Benjamin Liles
on
Oct 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 by
Ricardo Newbery
on
Oct 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 by
pierre gayvallet
on
Jan 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 by
pierre gayvallet
on
Jan 31, 2008 05:51 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 by
Ricardo Newbery
on
Feb 06, 2008 03:21 AM
Found a potential source for the unresolved conflicts. Fixed in svn... http://dev.plone.org/collective/changeset/58318
Issue state:
open
→
in-progress
Let me know if this fixes your usecase so I can close this ticket.
Added by
pierre gayvallet
on
Feb 27, 2008 05:04 PM
Yes, this actually fix the problem. No more conflictError on the tool class during transactions.
Thanks
Added by
Ricardo Newbery
on
Apr 04, 2008 01:06 AM
Fixed in 1.1.1
Issue state:
in-progress
→
resolved
Target release:
None
→
1.1.1
No responses can be added.
If you can, please log in before submitting a reaction.

extract.log