971183 - [email] ask for wifi wake lock when doing a sync

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[James Burke [:jrburke]]

It was unclear if a wifi wake lock should be attempted always when doing a periodic sync. However, after further discussion, tracked in bug 907028, the email app should just always request a wifi wake lock and release it as part of sync. It does not hurt to do it even if there is no network or cell connection is used. Down the road, there may be a 'connection' wake lock type we can use to make the intent clearer, mentioned in bug 907028 comment 12.

Comment 1

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

Warning, sorta rambly thoughts here:

The back-end already has some resource management stuff in place that relates to being online.  Specifically:

- Connections are explicitly owned by someone and released when that someone is not active.

- (Folders have mutexes which must be held in order to ask for a connection in that folder.)

- We have per-account queues for operations to be run against the server.


We have the current sorta-foolish things going on, connection-wise:

- We never explicitly kill our IMAP connections.  They just hang-out until they die even once released.

- As long as a slice is open in a folder, our ImapFolderConn keeps the connection checked out from the account.  This was done for:
-- IDLE/other reasons that we don't actually leverage
-- to avoid constantly SELECT/EXAMINEing folders based on locality; if the user is looking at a folder, we can expect we are going to be doing other stuff in that folder.


It sounds like the pseudo-code would go roughly something like this (ignoring our existing logic in the front-end).  Let's have the concept of liveAtLeast(seconds) ensuring the wifi wake-lock gets held for at least that many seconds.

- Have a cpu/wi-fi wake-lock with a timer.  We're always counting down to releasing our wake-lock.

- If something asks for us to create an IMAP/POP3/SMTP connection, liveAtLeast(OPENCONN)

- For syncs (which covers ActiveSync too), liveAtLeast(SYNCSTART).  On (notable) progress, liveAtLeast(SYNCALIVE).  When the sync completes we just let the timer keep running since there's A) a high probability that either the user will do something that still needs the connection or B) a high probability if this was an offline sync that we'll close the app soon, which inherently releases our wake-lock.  If it was a periodic sync but we're sticking around, at least if there was a notification that we generated, there is a probability the user will display the message again soon.

- When ImapFolderConn.withConnection() is invoked, as all online server operations like to do, liveAtLeast(ONLINEOP)

- When a server operation completes and there's some online ops in the queue but we have some local ops getting in-line ahead of the server ops, liveAtLeast(SERVERGRACE).  We'd only do this on the transition from server ops to local ops; not for every local op, but we'd have this be at least a few seconds.


I think the key rationale behind a strategy like this is:

- If the user is using the e-mail app, the connection is already assured by the screen being on, BUT, there is always the potential for them to get slightly ahead of us and then shut off the display, in which case it is nice to have the wake-lock held because of the side effects of the user using the app so that we have time to sync those all to the server.

- All the liveAtLeast stuff has the nice side-effect that it is also contingent on us making forward progress.  In the event a bug causes our logic to drop the async baton on the ground and never release an internal resource, liveAtLeast's timer will still run out and drop the wake-lock.  This also means that if we've got wi-fi but the connection has ridiculously low throughput, the timer will still fire and we'll give up (with some probability).  This seems nice too.


The downsides are that liveAtLeast versus a more explicit 'active process happening that tracks there are things going on or imminently going on' is seriously ad hoc and we could find ourselves peppering liveAtLeast calls throughout the code-base.  The active process tracking potentially require us to have no bugs or at least no bugs in our failsafe mechanisms for aborting long-running jobs.  I suppose we could also just have a timeout that marks a process that's keeping the wake-lock alive for some ridiculously long time as "probably dead" and stop figuring that into things.  Another alternative is to combine the process tracking with liveAtLeast() so the liveAtLeast() is happening on an explicitly tracked session thing.  When those finish, we remove them from wake-lock consideration, but do still sprinkle a few liveAtLeast() calls around for locality purposes; we really just need this to bridge between server operations being scheduled and/or acquiring connections as they take and release them.  I suppose just having the account create an activity of "burn down the server operations to zero" once it gets started could work...

Comment 2

[BMO Automation]

Firefox OS is not being worked on