RootObject:+login timeouts - no visibility into cause

[Robert Collins]

 22 SELECT lag + (CURRENT_TIMESTAMP AT TIME ZONE $STRING - updated) FROM DatabaseReplicationLag WHERE node=$INT:
   GET: 22 Robots: 16 Local: 0
      1 https://answers.launchpad.net/ubuntu/+source/firefox-3.0/+question/39643/+history/+login (RootObject:+login)
       OOPS-1935DS606
      1 https://answers.launchpad.net/ubuntu/+source/grub2/+question/149367/+edit/+login (RootObject:+login)
       OOPS-1935AU594
      1 https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/152947/+subscribe/+login (RootObject:+login)
       OOPS-1935CP427
   [19 other URLs]

10 second gap; wgrant says this is doing a backend http call to sso. Getting an exception in place for it.

Action items:
 - add the sso calls to the timeline so we gather data
 - when we have data showing the calls are <x seconds long> discuss with SSO about expected service level etc
 - we may have future issues being a openid client given this; so may need to custom-tune the timeout for this scenario or some such.

[Robert Collins (lifeless)]

I'm going to snarf this bug for adding measurements on our end. When they are in place, we can trigger a manual oops, or remove the override and see how long its actually taking.

[Launchpad QA Bot (lpqabot)]

Fixed in stable r12907 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/12907>.