WebDAV lock times out

[Rob5624]

I have the following set up: Alfresco Community version 4.2e on a desktop and oXygen XML Author on a notebook. I connected oXygen to Alfresco using WebDAV and all seems working OK. However when I open (and edit) a topic or a map in oXygen and keep the item open for some time (more than a minute or two, not yet able to time it completely) I noticed that closing the item did not result in the removal of the lock sign in the Data Source browser. It took some time before I figured out that the problem appears to be the Alfresco installation: for some reason the lock as present in Alfresco is removed after the mentioned time thereby resulting in an unable to unlock on closure. When trying to reopen the item oXygen returns with the 423 item locked message, which is oXygen internally generated. For me this is strange since I guess the lock message sent to Alfresco should be such that the lock is persistent until the unlock message is sent. It may be that I need to change a setting in Alfresco, but so far did not find the exact location for that.
Is this phenomenon known and when so is this only related to Alfresco (or does it also appear in connections with SharePoint?) and is there a (simple) solution for?
Many thanks!!!

[Rob5624]

I tried to increase the <session-config><session-timeout> from 60 to 600 and later to 7200.
However although the lock was persistent a bit longer the result was worse: during the running time-out the items could not be re-locked after unlocking.

This timeout is set in ...\Alfresco\tomcat\webapps\share\WEB-INF\web.xml

Btw: after the lock disappeared in Alfresco the only way to reopen an item was by checking the item out in Alfresco and undo the checkout immediately thereafter. Clumsy and not the way to go for

[adrian]

Hi,

I can't reproduce this error (423) with a generic WebDAV server and I'm not sure how Alfresco handles this. You should only get such an error (423) if the resource has already been locked. Try refreshing the parent folder of the resource (press F5 after selecting it) in the Data Source view and check if the lock status of the file has changed. Note that if the resource is locked, you can look at its properties (right click on the resource in the Data Source view and pick Properties) and see the lock properties (token, depth, type, owner, scope).


When WebDAV resource locking is enabled (it is by default), Oxygen behaves like this:
When opening a resource via WebDAV, Oxygen locks it for 300 seconds (5 minutes). Every 150 seconds (2 and a half minutes) it attempts to renew the lock (for the same 300 seconds) of the opened resource. When closing the resource, the resource is unlocked. This is all transparent.

If for some reason the lock cannot be renewed within the 300 seconds time interval (e.g. network gets disconnected or computer is put to sleep), the lock expires. When you try to reopen the resource, Oxygen will report "412 Precondition failed" for the rest of the current session. After restarting the application it will no longer complain.

If this problem bothers you and you don't need the locking mechanism, you could disable it (at least temporarily) in: Options > Preferences, Network Connection Settings / HTTP(S)/WebDAV, Lock WebDAV files on open
Please note that without the locking mechanism, it's possible to encounter conflicts if other users are editing the same resource.

Regards,
Adrian

[Rob5624]

Hi Adrian,

Thanks for your reply. I tried the F5 also, but no luck, problem is that oXygen still thinks the resource should be locked (less than the mentioned 5 minutes). Problem is that the Alfresco side is no longer locked... I need to try what happens when I save regularly within 2.5 minutes time from previous save... maybe it then "keeps" the lock on Alfresco side... As I mentioned I played with the timeout and the lock disappeared after about 5 minutes in Alfresco when the session timeout was set to 10 minutes... I guess I need to tweak the Alfresco installation, but not yet a clue where to start, the session timeout definitely had some effect, but the result of an increased timeout was worse than losing the lock, after repair on "Alfresco side" the lock could not be reapplied from within oXygen (hope this makes sense, it does for me while testing ).
Anyway disabling the locking while testing is no problem, but the idea is to roll out the combination of oXygen and a CMS to multiple users and then the locking is needed. I can also use a SharePoint CMS system, so I need to have a look at that as well to see whether the locking mechanism works OK with SharePoint... So I am not stuck... but still wants to understand what is wrong... or not set correctly for that matter.

[adrian]

Hi,

I've sent you a private email with details for enabling logging in Oxygen, so that we can look into this.

Regards,
Adrian

[Rob5624]

Hi Adrian, THANKS! Reply is on it's way to you!

[adrian]

Hi,

In case anyone else encounters this, a bug has been filed on the Alfresco bug tracking system:
https://issues.alfresco.com/jira/browse/MNT-10908

Regards,
Adrian