558542 - 1st run of 1.2 results in non-responsive script warning

Status: RESOLVED WORKSFORME

(Cloud Services :: General, defect)

Description

[Bill Sherman]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (.NET CLR 3.5.30729)

Had Weave 1.1 installed and running successfully on 4 clients for a few weeks. Was notified today that Weave 1.2 was available so I updated to 1.2 on one client. When the 1st sync attempt was made on that client, Mozilla warned that a Weave script (Engine) was non-responsive. I let it continue (by clicking continue) several times but the issue did not resolve.

Reproducible: Always

Comment 1

[Bill Sherman]

Attachment: verbose-log.txt

I believe that the entries at (and after) 2010-04-10 07:59:30 are from when I restarted Firefox to deinstall Weave.

Comment 2

[Ed Lee :Mardak]

Could you put this into Tools -> Error Console to see how many form entries you have? It sounds like you have a lot and Weave is trying to sync too many at the same time:

Components.utils.import("resource://weave/util.js"); q = Svc.Form.DBConnection.createStatement("SELECT COUNT(*) n FROM moz_formhistory"); q.executeStep() && q.row.n

You might want to clear the Error Console and select the All tab to see the number easier.

Comment 3

[Ed Lee :Mardak]

Attachment: v1

At least for me..

Components.utils.import("resource://weave/service.js"); s=Date.now(); Weave.Engines.get("forms")._store.getAllIDs(); Date.now() - s

That takes about 1.3-1.4 seconds.

With this patch, it takes ~40ms.

I have 3150 entries, so doing a select to get each guid takes about .4ms per request, but it adds up.

There's still a separate issue of settings the guids in the first place..

Comment 4

[Ed Lee :Mardak]

We need one of those fancy flags!

blocking-1.2  [.1?]

Comment 5

[Bill Sherman]

Ed, I removed 1.2 from the client that experienced the error so I am not currently able to execute that code to count the entries. I went to another client and performed the "reset the server" process, then uploaded good data from that 1.1 client, so I'm good with all of my other clients at this point. Is it valid to execute that code on one of the "good" 1.1 clients? I believe that all clients have been fairly recently synchronized so the counts should be comparable.

BTW I'm selective about what I synchronize -- passwords, bookmarks, and history, NOT tabs or preferences. Does that make any difference?

- Bill

Comment 7

[Phil Stracchino]

I get 7492 returned by the above code on the machine that is experiencing a problem, 219 on one of the machines that isn't.  These two machines were THEORETICALLY fully synced.

Comment 8

[Mike Connor [:mconnor]]

Comment on attachment 438267 [details] [diff] [review]
v1

Yeah, that'll be slow all right, especially in the thousands-of-records case.

Comment 9

[Bill Sherman]

Ed/Mike,

Sounds as though you are saying that the non-responsive script is fine, just slow, so that if I kept clicking "continue" that it would [probably] eventually complete?

Should I install 1.2 again and then apply the patch (attached above) before performing a full synch with 1.2?

Alternatively, is there a way I can obtain version 1.1? When might the patch be included in the mainstream version (1.2+, or whatever)?

Sorry/Thanks!
Bill

Comment 10

[Phil Stracchino]

FYI, I tried applying the patch from attachment 438267 [details] [diff] [review], then re-enabled Form History, initiated a sync, and allowed it to run.  Firefox again became completely unresponsive, and had been unresponsive for several minutes at 100% CPU usage at the point I finally killed it.

I'd suggest a progress meter incrementing every hundred records or so, but that's not going to help anything when the entire GUI is completely unresponsive and not even being redrawn on exposes.

Comment 11

[Ed Lee :Mardak]

Attachment: v2

Also this is less of an issue now that we sync only a limited number of form items instead of everything.

Comment 12

[Ed Lee :Mardak]

Seems to work for me now that we don't sync a ton of form entries. I can't even trigger the slow script with a really short timeout. So maybe the async network/sql queries are breaking things up as well.