493848 - gloda activity manager should not create events for event-driven indexing, never display in status bar

Status: VERIFIED FIXED

(Thunderbird :: Search, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

Based on discussion with clarkbw and davida, it was determined that we should not display anything in the activity manager for event-driven indexing.

The rationale is that event-driven indexing is always happening, and:
1) Having tons of event-driven event (log) entries in the activity manger is not helpeful.
2) Having a process continually flickering into and out of existence in the activity manager is also not helpful.

This will leave the indexing sweep as the only valid source of gloda events in the activity manager.  (And then, only for the folder indexing triggered, not the self-rescheduling sweep job.)

Comment 1

[Wayne Mery (:wsmwk)]

Andrew, 
does this also tie in to activity seen in status bar?
is this perhaps easy for someone to drive in for say v3.1?

Comment 2

[Andrew Sutherland [:asuth] (he/him)]

The activity manager tells the status bar about things, yes.  I certainly didn't go out of my way to add some UI that makes everyone blame everything on gloda ;)

It would be good to likely spend some small amount of time to make gloda less concerning to people in terms of its reporting.  I'm inclined to stop all gloda events from showing up on the status bar.  It's not particularly useful information*, and it seems to irritate people who become concerned that gloda has gone rogue.  (I concede that the apparently ever increasing message count is something to be concerned about... that will be fixed as part of the deletion fixin')

* Gloda's activities are never the result of a user action nor do they ever block user interaction.  Which is to say, telling a user that we finished sending their e-mail is informative to them.  Likewise, telling a user that the reason the UI is not doing anything is because we are loading a folder is also informative to them.

Comment 3

[Wayne Mery (:wsmwk)]

great. so, even though the need for this will decrease in terms of seeing fewer examples as things get fixed, I will assert that for user and our sanity (when we get 10x more users) we should _want_ this for v3.1. (but not blocking)  I suspect Roland will agree. 

Further to your point - I won't comb gsfn right now - there are plenty of topics that state this is an outright problem, or cite it in relation to some other, unrelated issue. Which tends to make them less difficult to troubleshoot

Comment 4

[Ludovic Hirlimann [:Usul]]

(In reply to comment #2)
 
> * Gloda's activities are never the result of a user action nor do they ever
> block user interaction.  Which is to say, telling a user that we finished
> sending their e-mail is informative to them.  Likewise, telling a user that the
> reason the UI is not doing anything is because we are loading a folder is also
> informative to them.

One piece of information I find usefull is to know If I'm indexing or not. If I am then I have no issues having bad results on serach If I'm not I'm going to feel that there's a catch somewhere. Can we keep something in the activity manager somehow. And Yes It's an edgecase, but very handy to easily check things without having to install an extension (Glodaquilla) to figure things out.

Comment 5

[Andrew Sutherland [:asuth] (he/him)]

We definitely want to be able to know if gloda is actively indexing.  I'm just proposing we don't need to expose that on the status bar.

Comment 6

[Dennis Jacobfeuerborn]

> * Gloda's activities are never the result of a user action nor do they ever
> block user interaction.  Which is to say, telling a user that we finished
> sending their e-mail is informative to them.  Likewise, telling a user that the
> reason the UI is not doing anything is because we are loading a folder is also
> informative to them.

Users still have to know that TB is busy and give some indication for how long it's going to stay that way. A few days ago Gloda was re-indexing a large folder and that caused 100% cpu usage for about 30 minutes.
I should be able to a) tell that this is intended b) see some sort of progress to see if whatever TB is doing is actually progressing and how long it will approx. take until it is done.
Making this information no longer available would probably lead me to believe that whatever is going on is a bug and potentially messing with my e-mail. Not good.

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

The activity manager will still be available and provides much more reliable indicators of what is happening.

100% cpu usage suggests it was actually gloda deletion processing in a pre-3.1 beta 2 build.  I would suggest trying a 3.1 beta 2 build or a 3.0.x nightly from tomorrow (fix just landed).

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

Er, I realize my last comment is not entirely consistent with the rest of the bug.

My main goal is to stop us confusing the user with the status bar.  We also want to avoid having useless permanent entries in the activity manager.  We absolutely always want the activity manager to tell the user gloda is doing things; we just may not convert those to permanent records once the specific indexing job is completed.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

Attachment: v1 do not show gloda activity in the status bar, only create events for non-event-driven folder indexing

The patch is surprisingly simple.  I argue for 3.1 since it will greatly simplify support efforts for 3.1 to not have everything blamed on gloda just because it is on the status bar with high probability.

clarkbw, I'm pretty sure you're on board with the concept, but please explicitly provide confirmation via a sign-off.

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

Comment on attachment 444105 [details] [diff] [review]
v1 do not show gloda activity in the status bar, only create events for non-event-driven folder indexing

oh yeah!  All gloda does is talk, talk, talk

Comment 11

[Mark Banner (:standard8)]

Comment on attachment 444105 [details] [diff] [review]
v1 do not show gloda activity in the status bar, only create events for non-event-driven folder indexing

Yep, I think this is a reasonable solution based on where we are, and cutting down the noise.

Comment 12

[Andrew Sutherland [:asuth] (he/him)]

(Also, the spinner takes a disturbing amount of CPU on linux still...)

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

pushed to comm-1.9.2:
http://hg.mozilla.org/releases/comm-1.9.2/rev/dadc34656c4a

pushed to comm-central:
http://hg.mozilla.org/comm-central/rev/5d4478a6a2f9

I will post to MDAT about this change to provide general awareness of the change in behaviour.

Comment 14

[Wayne Mery (:wsmwk)]

(In reply to comment #12)
> (Also, the spinner takes a disturbing amount of CPU on linux still...)

so also a perf win. I've read the linux bug but don't have a bug# at hand. :(

Thanks Andrew! Verified that indexing status is not in status bar, does show in activity manager, with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.5pre) Gecko/20100511 Lanikai/3.1pre