User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 Build Identifier: 1.0 Fails to sync after resuming from standby. Happens everytime, and requires a restart of Firefox to work again. Error is as follows: 2010-02-05 17:39:58 Service.Main DEBUG Exception: Could not acquire lock No traceback available 2010-02-05 17:40:03 Service.Main DEBUG Idle timer created for sync, will sync after 5 seconds of inactivity. Reproducible: Always Steps to Reproduce: 1. enter standby 2. resume from standby 3. Weave then fails to sink until Firefox is restarted. Actual Results: N/A Expected Results: To sync normally
The above errors occur regularly until Firefox is restarted.
This also occurred in all the RC versions.
Noticed it also does this on Windows 7 sometimes (i.e. after resume from standby), not as often as on the Mac.
I've hit this three times in the last week. Whack. A. Mole.
Assignee: nobody → edilee
Status: UNCONFIRMED → NEW
Ever confirmed: true
Any idea if Weave was trying to sync and then you put the laptop to sleep? How about the type of internet connection. I'm assuming it's wireless in all cases, but how about the quality of the connection?
Usually wireless, but sometimes I'll switch from wired at office to wireless at home.
LAN only connection here, no connection issues here. Possibly it happens as synching when I go to standby but I doubt it as this happens every time I go to standby.
Does this happen when sleep/resume on the same connection? I just tried sleeping in the middle of uploading ~500 history items and the first time I waited several seconds before resuming then the second time I waited several minutes and the sync still completed successfully. I'm not sure if I was in the middle of a transfer when it went to sleep, so there might have been no network activity when actually sleeping. Maybe if I try on a slower connection where the upload will definitely be cut off.. or switch networks.
Can't fully confirm this yet but since v1.0.1 I don't appear to have experienced this problem.
Forget the above comment, the problem is still there.
Assignee: edilee → nobody
Component: General → Sync
QA Contact: general → sync
Comment on attachment 436126 [details] [diff] [review] v1 Five minutes seems high if we're bumping it onDataAvailable... I would say that if we're a minute of inactivity we should bail then. Hitting a server that's this slow probably means we should fail aggressively and enter backoff... r=me with a change to a one minute timeout.
Attachment #436126 - Flags: review?(mconnor) → review+
Part of the reason for such a high timeout is that each onDataAvailable could contain multiple records, and we won't get another oDA until we finish processing all the records. But I suppose slow processing of records is somewhat a bug. There's been reports of people syncing one bookmark into a folder with thousands of bookmarks takes a few minutes.
http://hg.mozilla.org/labs/weave/rev/72753a058be3 Start an abortTimer onStartRequest and refresh the timer on each onDataAvailable only to cancel on an onStopRequest. If the timer triggers, the sync/async call will be aborted.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: [has patch][needs review mconnor]
need a FFT litmus test on recovering from standby. flagging in-litmus?
moving manual test cases to moztrap
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.