touch-packages team mailing list archive

[Michi Henning <michi.henning@xxxxxxxxxxxxx>]

Public bug reported:

I'm seeing this on Mako, image #63, devel-proposed.

Periodically, the music scope fails to return any results, leaving a
blank screen.

Looking through the log files, I'm seeing tons of messages such as this:

[2015-01-13 01:33:27.056262] INFO: SSRegistry: SmartScopesClient.get_remote_scopes(): GET https://dash.ubuntu.com/smartscopes/v2/remote-scopes?locale=en_US
[2015-01-13 01:33:27.057239] ERROR: SSRegistry: SmartScopesClient.get_remote_scopes(): failed to read /custom/partner-id: unity::FileException: cannot open "/custom/partner-id": No such file or directory (errno = 2)
[2015-01-13 01:33:46.996259] ERROR: SSRegistry: SmartScopesClient.get_remote_scopes(): Failed to retrieve remote scopes from uri: https://dash.ubuntu.com/smartscopes/v2/remote-scopes: unity::ResourceException: Request timed out: https://dash.ubuntu.com/smartscopes/v2/remote-scopes?locale=en_US

The request times out even though the remote end works fine. (Easy to
confirm by pasting the same URL into the browser.)

As an aside, the error about /custom/partner-id isn't an error: if the
file doesn't exist (errno = 2), we should say nothing. That'll get rid
of a lot of noise.

In addition, when I run a query, I see all queries to remote scopes fail
(see attached trace).

I'm not familiar with the code. Looking through, I noticed this:

HttpResponseHandle::SPtr response = http_client_->get(remote_scopes_uri.str(), [&response_str](std::string const& replyLine) {
                response_str += replyLine; // accumulate all reply lines
        }, headers);
        response->get();

Following this through, it appears that response_str is being appended
to from a different thread without any lock. That looks like it's wrong
to me. But that doesn't explain the timeout exception that is thrown
from response->get().

I suspect a race condition somewhere because, occasionally, I get a
query that works.

** Affects: unity-scopes-api (Ubuntu)
     Importance: Critical
         Status: New

** Attachment added: "smartscopesproxy.log"
   https://bugs.launchpad.net/bugs/1409995/+attachment/4296921/+files/smartscopesproxy.log

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity-scopes-api in
Ubuntu.
https://bugs.launchpad.net/bugs/1409995

Title:
  Queries to remote scopes time out

Status in unity-scopes-api package in Ubuntu:
  New

Bug description:
  I'm seeing this on Mako, image #63, devel-proposed.

  Periodically, the music scope fails to return any results, leaving a
  blank screen.

  Looking through the log files, I'm seeing tons of messages such as
  this:

  [2015-01-13 01:33:27.056262] INFO: SSRegistry: SmartScopesClient.get_remote_scopes(): GET https://dash.ubuntu.com/smartscopes/v2/remote-scopes?locale=en_US
  [2015-01-13 01:33:27.057239] ERROR: SSRegistry: SmartScopesClient.get_remote_scopes(): failed to read /custom/partner-id: unity::FileException: cannot open "/custom/partner-id": No such file or directory (errno = 2)
  [2015-01-13 01:33:46.996259] ERROR: SSRegistry: SmartScopesClient.get_remote_scopes(): Failed to retrieve remote scopes from uri: https://dash.ubuntu.com/smartscopes/v2/remote-scopes: unity::ResourceException: Request timed out: https://dash.ubuntu.com/smartscopes/v2/remote-scopes?locale=en_US

  The request times out even though the remote end works fine. (Easy to
  confirm by pasting the same URL into the browser.)

  As an aside, the error about /custom/partner-id isn't an error: if the
  file doesn't exist (errno = 2), we should say nothing. That'll get rid
  of a lot of noise.

  In addition, when I run a query, I see all queries to remote scopes
  fail (see attached trace).

  I'm not familiar with the code. Looking through, I noticed this:

  HttpResponseHandle::SPtr response = http_client_->get(remote_scopes_uri.str(), [&response_str](std::string const& replyLine) {
                  response_str += replyLine; // accumulate all reply lines
          }, headers);
          response->get();

  Following this through, it appears that response_str is being appended
  to from a different thread without any lock. That looks like it's
  wrong to me. But that doesn't explain the timeout exception that is
  thrown from response->get().

  I suspect a race condition somewhere because, occasionally, I get a
  query that works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/unity-scopes-api/+bug/1409995/+subscriptions