Ticket #13320 (confirmed Bug)
externaledit timeout too short
Reported by: | dturvene | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.x |
Component: | Backend (Python) | Version: | 4.2 |
Keywords: | externaledit, webdav, zopeedit, timer, upstream | Cc: |
Description
I upgraded from 3.X (3.3? pretty old) to 4.2.1 on an Ubuntu 12.04 LTS virtual server. The way we have operated for years is: each author uses the external editor to load multiple pages into an emacsclient session and edit them progressively throughout the day (e.g. development logs, research, activities, meeting minutes, etc.) We have perhaps five years of information in ReST-formatted documents. It is an efficient mechanism to capture information and the Zope search capabilities are great.
However, after upgrading we noticed that some of the external edit sessions expired silently and fairly quickly, causing edits to be lost.
We tracked the problem to webdav/LockItem.py with a 12 minute lock timeout. If no activity in 12 minutes, the lock is released and all subsequent external edits are lost. With 4+ external edit sessions this was frustrating.
Two work arounds: 1) Change the webdav/LockItem.py DEFAULTTIMEOUT to something useful. For some reason LockItem.py converts "infinite" to 12 minutes - less time than I've been working on this issue report. The downside to this is we are 1: changing the distro code 2: page is locked for a long period unless explicitly unlocked. 2) Change the "Timeout" value from "infinite" to something concrete. The downside to this is only 2: page is locked for a long period unless explicitly unlocked.
We are using workaround 2 for our solution and are happy.
I looked at the code in the plone.locking package about stealable locks but didn't get far. Also, not entirely germane to our use.