544532 - Weave won't sync after resume from standby

Status: VERIFIED FIXED

(Firefox :: Sync, defect)

Description

[email]

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

Comment 1

[email]

The above errors occur regularly until Firefox is restarted.

Comment 2

[email]

This also occurred in all the RC versions.

Comment 3

[email]

Noticed it also does this on Windows 7 sometimes (i.e. after resume from standby), not as often as on the Mac.

Comment 4

[Mike Connor [:mconnor]]

I've hit this three times in the last week. Whack. A. Mole.

Comment 5

[Ed Lee :Mardak]

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?

Comment 6

[Mike Connor [:mconnor]]

Usually wireless, but sometimes I'll switch from wired at office to wireless at home.

Comment 7

[email]

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.

Comment 8

[Ed Lee :Mardak]

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.

Comment 9

[email]

Can't fully confirm this yet but since v1.0.1 I don't appear to have experienced this problem.

Comment 10

[email]

Forget the above comment, the problem is still there.

Comment 11

[Ed Lee :Mardak]

Attachment: v1

Comment 12

[Mike Connor [: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.

Comment 13

[Ed Lee :Mardak]

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.

Comment 14

[Ed Lee :Mardak]

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.

Comment 15

[Tony Chung [:tchung]]

need a FFT litmus test on recovering from standby.  flagging in-litmus?

Comment 16

[Tracy Walker [:tracy]]

moving manual test cases to moztrap