It should not be possible to have multiple lock requests at the same time

RESOLVED FIXED

Status

RESOLVED FIXED
10 years ago
9 years ago

People

(Reporter: hello, Assigned: anant)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

10 years ago
Currently if there is a lock request in process (we are waiting for an XHR response) and lock is called again, the service/dav code will initiate a second lock request.

That is wrong, and in the case where the server is down and requests don't time out, will cause lock requests to stack up.
(Assignee)

Comment 1

10 years ago
Created attachment 326945 [details] [diff] [review]
Disable multiple lock requests

This patch sets an internal _lockAllowed property whenever a lock request is made, and checks if it is not set before actually making the request. This prevents mutiple lock requests from being made at the same time.

We also throw an exception if an attempt to lock is made when another lock request is already progressed. This exception is specially handled by async.js to print only a warning and not the full stack trace.

Here is a sample log from my test of the patch:

2008-06-26 10:27:10	Chrome.Window	INFO	Logging in...
2008-06-26 10:27:10	Chrome.Window	INFO	User string: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0
2008-06-26 10:27:10	Chrome.Window	INFO	Weave version: 0.1.31
2008-06-26 10:27:10	Service.Main	DEBUG	Logging in user test
2008-06-26 10:27:10	Service.Main	INFO	Using server URL: https://services.mozilla.com/0.2/user/test/
2008-06-26 10:27:10	Service.DAV	DEBUG	GET request for meta/version
2008-06-26 10:27:10	Service.Main	INFO	Weave scheduler enabled
2008-06-26 10:27:10	Chrome.Window	INFO	Login successful
2008-06-26 10:28:10	Service.Main	INFO	Running scheduled sync
2008-06-26 10:28:10	Service.DAV	DEBUG	LOCK request for lock
2008-06-26 10:29:10	Service.Main	INFO	Running scheduled sync
2008-06-26 10:29:10	Async.Generator	WARN	Exception: Cannot acquire lock (internal lock)
2008-06-26 10:29:25	Service.DAV	WARN	_makeRequest: got status 0
2008-06-26 10:29:25	Async.Generator	ERROR	Exception: [object Object]
2008-06-26 10:29:25	Async.Generator	DEBUG	Stack trace:
No traceback available.
This exception was raised by an asynchronous coroutine.
Initial async stack trace:
unknown (async) :: WeaveLockWrapper-7
module:wrap.js:91 :: WeaveNotifyWrapper
module:service.js:264 :: WeaveSync__onSchedule
module:util.js:399 :: innerBind
module:util.js:439 :: EL_notify

Note that the second exception is from the first lock request timing out and receiving a status of 0, which must be handled correctly (that's for another bug).
Assignee: nobody → anarayanan
Status: NEW → ASSIGNED
Attachment #326945 - Flags: review?(thunder)
(Reporter)

Comment 2

10 years ago
Comment on attachment 326945 [details] [diff] [review]
Disable multiple lock requests

>diff -r 4d2a03483701 modules/async.js
>--- a/modules/async.js	Wed Jun 25 17:11:01 2008 -0700
>+++ b/modules/async.js	Thu Jun 26 10:32:20 2008 -0700
>@@ -192,6 +192,8 @@
> 
>       this._exception = e;
> 
>+    } else if (e.message && e.message == 'Cannot acquire lock (internal lock)') {
>+      this._log.warn("Exception: " + Utils.exceptionStr(e));

r+ except for this change.  I do want us to supress the stack trace, but not in async.js, since it's a weave/dav implementation detail and not related to async.js.

Perhaps we can catch it in the lock wrapper (wrap.js) instead.  But note that it'll be an AsyncException.

Looks good, otherwise.
Attachment #326945 - Flags: review?(thunder) → review+
(Assignee)

Comment 3

10 years ago
Checked-in a995c93356b0. We're going to be looking into exception handling separately.
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

9 years ago
Component: Weave → General
Product: Mozilla Labs → Weave
Target Milestone: -- → ---
QA Contact: weave → general
You need to log in before you can comment on or make changes to this bug.