Uploader: Allow easier recovery from stale WebDAV locks

[dscho]

When uploading, first thing is that the db.xml.gz file is locked via WebDAV. However, if the computer crashes, or ImageJ, or the updater, before the upload completes, the lock is not removed.

To allow recovery, we should log the LOCK token and have a little interactive helper (probably in the src/test/java/ part of plugins/uploaders/webdav/) to force-unlock.

This would have helped @iarganda with the problem he reported in http://fiji-devel.54424.x6.nabble.com/unable-to-upload-the-new-version-of-my-plugin-td1435.html...

[ctrueden]

It might be sufficient to provide a force-unlock feature from the updater itself (command line and UI)?

[dscho]

Hmm. Would this not

1. be rarely used (hopefully)?
2. a huge effort to bring into the UI?
3. another huge effort to make sure that the latest lock token is remembered?

I think that the changes I proposed would take me about two hours. The UI-based solution would take me two days. And it would clutter the UI even more, and users would click it by mistake.

[ctrueden]

I have a hard time believing that adding this to the UI would take more than a few minutes, but I don't know the code, so I will defer to you on it.

Personally I just hate it when the solution to a blocker like this is "wait 30 minutes" as opposed to "click a button to tell the computer I know better."

[dscho]

Remember how I told you (in person) how lousy a designer I am and that I always take too many iterations to get it right?

This would be a prime example: you need the lock token to unlock. Where would the button know this token from? Especially if somebody else borked the upload? Next problem: unlock only applies to WebDAV. WebDAV is a plugin to the updater. The button would need to live in the UI. To connect them, the Uploader interface needs to be enhanced, breaking backwards-compatibility (or using duck-typing, of course). And then, pilot errors are much more likely if such a button exists. Pretty unwieldy problem all of a sudden, right?

[ctrueden]

The button would do the following:

• Get the directory listing from the update site; e.g.: http://sites.imagej.net/LOCI/
• For each db.xml.gz.lock file (or whatever the pattern is, I forget), issue a DELETE command via WebDAV/SSH/whatever mechanism (uploader interface would need a delete method if it doesn't have one already).
• Voila, you can upload again. And if you stomped someone else, that's your fault. If this possibility worries you too much, only allow this for "personal update sites" named the same as the username, since those are unlikely to be shared.

I'm not pushing for this, just explaining my thinking...

[dscho]

For each db.xml.gz.lock file...

Unfortunately, it is not that easy. Remember, WebDAV was designed by Microsoft. You do not have .lock files. Locks are stored in a BerkeleyDB whose path is specified by the DavLockDB statement in the Apache configuration. This DB stores a binary blob consisting of an ad-hoc-serialized object that contains the timestamp, the timeout, the user, probably the token, and the path.

This database cannot be accessed via the browser. It is not even possible to just list all current locks, not even from the command-line. It is not possible to delete a lock from the database via the command-line because it is only persisted state living inside Apache. The only way you can remove the lock is by issuing an UNLOCK request with the proper credentials and the correct lock token (which I might be able to extract from the lock database once I understand its format and single-stepped through a sample upload).

I am glad that you made me write this up because that way, I can gladly forget about it and look it up in the future when needed.

[ctrueden]

Thanks for the explanation. That is indeed horrible. Maybe the timeout could be 10 minutes instead of 30, then?

[dscho]

I thought about that, but rejected the idea for being too fragile.

But since you also had this idea, it's probably good! See efb9e80

[ctrueden]

since you also had this idea, it's probably good

Hey, you've got something on your nose there... 😉

rejected the idea for being too fragile.

Sure, any given timeout has the potential to be too short, if your internet connection is crappy enough (and/or your updates being uploaded are huge enough). But at least 99% of the time I think it'll be fine. And the other 1%, the chances of a second person trying to upload changes to the same update site at the same time are next to nil.

[dscho]

I'll close this for now, even if no new webdav uploader has been released with the fix yet; this will be done in the context of the big "beta 8" upload that I have been preparing for all week long (or so it seems).