Closed Bug 812101 Opened 10 years ago Closed 10 years ago

Account provisioner: First search with both Gandi & Hover checked, fails most of the time


(Thunderbird :: Account Manager, defect, P2)

16 Branch


(thunderbird17+ fixed, thunderbird18+ fixed, thunderbird-esr1718+ fixed)

Tracking Status
thunderbird17 + fixed
thunderbird18 + fixed
thunderbird-esr17 18+ fixed


(Reporter: jb, Assigned: sancus)



- Search for an email address with totobimbo, with Gandi & Hover checked: failure (most of the time) at first search. 
- Deselect one of the providers and run search again: successful (even if Gandi results are broken - they seem to be expecting 2 words search query and use the second for the domain name )
- Reselect the previously deselected provider and run the search again: success
Blake/Sancus: please take a look at this. It clearly isn't working consistently.
I worked through this with Sancus this morning. We reduced it down to one main issue, and one minor issue that we want to follow-up on as well (plus one issue already fixed):

* The main issue is that the account provisioning providers are being talked to in an synchronous fashion. At the moment, hover is taking about 7.5 - 8.5 seconds to respond, gandi is between 1 - 4 seconds.

Thunderbird has a built in timeout of 10 seconds.

Hence, there are various times when we're taking up to about 11/12 seconds to get a result, and so Thunderbird is timing out. I'm guessing about 30 - 50% of the time we could be getting timeouts at the moment. We have no history here, so we don't know how long we've been in this state.

Sancus is planning on changing broker-live to run the providers as async (something that was originally intended), so once that is done, we should be a lot less likely to time out.

* The minor issue, is that broker-live also has a 10 second timeout on individual results, given that Thunderbird also has 10 seconds, that leaves no time for actual processing in the server picks up the timeout case, i.e. we could be in the state where a provider has timed out, but another provider has returned the results which broker-live would return, but Thunderbird would itself have timed out leaving the user with no results.

The simple fix here is to bump Thunderbird's timeout a little, so that it exceeds broker-live's timeout.

Given the times we're seeing for results to be returned on individual providers, I don't think we need to push this tweak out quick for 17.0, we can include it in the next round of security releases, as an worst case improvement.

* The fixed issue is that when requesting results for only one provider, broker-live was still asking both/all providers (in the synchronous fashion as mentioned above).

This is now fixed on broker-live and, for instance, we're generally seeing 1-3 seconds on results from Gandi where it was around 10 seconds (and sometimes timing out) before.

So at the moment, searches on individual providers should now return results all of the time, and searches on both providers may time out - but Sancus will look at fixing that later today.
Assignee: nobody → sancus
Also, it's really kind of sad that it takes Hover 7+ seconds to return an API result.
This is fixed now, I've multiprocessed the code that requests data from provider APIs. I still feel that we should give Hover a shout and see if they can speed themselves up a bit, because a 7-second return is really bad when it could be 1-4 seconds instead if they at least matched Gandi's speed.

But that's for another bug.
Closed: 10 years ago
Resolution: --- → FIXED
Just resolving the flags - server side fix, so effectively fixed for everything.
You need to log in before you can comment on or make changes to this bug.