Weave won't sync after resume from standby

VERIFIED FIXED in 1.2

Status

Cloud Services
Firefox Sync: Backend
--
major
VERIFIED FIXED
9 years ago
6 years ago

People

(Reporter: email, Assigned: Mardak)

Tracking

unspecified
x86
Mac OS X
Points:
---
Bug Flags:
blocking-weave1.2 +
in-litmus +
in-moztrap +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 1

9 years ago
The above errors occur regularly until Firefox is restarted.
(Reporter)

Comment 2

9 years ago
This also occurred in all the RC versions.
(Reporter)

Comment 3

9 years ago
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
Flags: blocking-weave1.1+
(Assignee)

Comment 5

9 years ago
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.
(Reporter)

Comment 7

9 years ago
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.
(Assignee)

Comment 8

9 years ago
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.
(Reporter)

Comment 9

9 years ago
Can't fully confirm this yet but since v1.0.1 I don't appear to have experienced this problem.
(Reporter)

Comment 10

9 years ago
Forget the above comment, the problem is still there.
(Assignee)

Updated

8 years ago
Assignee: edilee → nobody
Component: General → Sync
QA Contact: general → sync

Updated

8 years ago
Target Milestone: --- → 1.2
(Assignee)

Updated

8 years ago
Assignee: nobody → edilee
(Assignee)

Comment 11

8 years ago
Created attachment 436126 [details] [diff] [review]
v1
Attachment #436126 - Flags: review?(mconnor)
(Assignee)

Updated

8 years ago
Whiteboard: [has patch][needs review mconnor]
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+
(Assignee)

Comment 13

8 years ago
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.
(Assignee)

Comment 14

8 years ago
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?
Flags: in-litmus?
moving manual test cases to moztrap
Status: RESOLVED → VERIFIED
Flags: in-moztrap+
Flags: in-litmus?
Flags: in-litmus+
You need to log in before you can comment on or make changes to this bug.