Closed
Bug 727395
Opened 12 years ago
Closed 12 years ago
fallback_node self.clean_location failure results in no clusterURL valu
Categories
(Cloud Services :: Server: Registration, defect)
Cloud Services
Server: Registration
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 721558
People
(Reporter: jethro.carr, Unassigned)
Details
Attachments
(3 files)
1.38 KB,
text/plain
|
Details | |
864 bytes,
text/plain
|
Details | |
656 bytes,
patch
|
Details | Diff | Splinter Review |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Iceweasel/9.0.1 Build ID: 20120106041658 Steps to reproduce: I have configured a Mozilla Sync Server from checked out trunk sources (not using the sync server build utilities) as part of distribution packaging. The components I have built and installed are: server-core, server-reg, server-storage and server-sync, using a SQLite backend. server-core trunk changeset da979263448c server-reg trunk changeset 2814b6167114 server-full trunk changeset 14a5c37fbfc2 server-storage trunk changeset 689923bdefff Actual results: When testing with various clients (Firefox 10 for Windows, Firefox 9 for Linux, and Firefox 9 for Android) I found that the sync setup process would complete and successfully register a user on the sync server, however the initial sync would fail and never take place, repeatedly failing and reporting that the server is busy. The issue occurs with the following call after registration before sync: GET /mozilla-sync/user/1.0/USERID/node/weave HTTP/1.1" 200 The call returns success, but never returns the value of nodes.fallback_node despite being configured correctly and expected as per the API specification. Example of configuration (full server configuration attached to bug report) [nodes] fallback_node = http://example.com/mozilla-sync/ To work around, I had to manually set the service.sync.clusterURL value in the Firefox client in order to get sync to occur. This was determined by digging through the mailing list which revealed a few similar faults had been fixed in this manner. Expected results: The services.sync.clusterURL value should have been set when the sync registration completed. Mozilla server-reg should be sending back the configured nodes.fallback_node value when the API call is executed so that the Firefox browser can configure accordingly. According the to the documented API at http://docs.services.mozilla.com/reg/apis.html, the call that is failing should return the node that the client is located on, the return of a null value indicates a server performance issue. Confirmed with packet dump that no clusterURL value was being returned. Annoyingly Firefox did not log an error because it considers the API call to still be a success, even if no clusterURL is returned. To figure out what is going on, you need to set services.sync.log.appender.file.logOnSuccess to True, attempt a sync, and then review the success logs at about:sync-log to see: 29298300464 Sync.Resource DEBUG GET success 200 http://example.com/mozilla-sync/user/1.0/bd2ytnv422t273fwunxsvdiduauv776o/node/weave 1329298300464 Sync.Service DEBUG Cluster value = null 1329298300464 Sync.Status DEBUG Status.sync: success.sync => error.sync.reason.no_node_found This full error file example from a Mozilla browser has been attached to this bug report for your reference.
Reporter | ||
Comment 1•12 years ago
|
||
Reporter | ||
Comment 2•12 years ago
|
||
I have attached a patch created which disables the URL validation in syncreg/controllers/user.py, the validation here seems to break the fallback_nodes return. This patch may cause security issues, I have only taken a brief look at the code base at this stage.
Comment 3•12 years ago
|
||
Updating to server-reg tip (or the rpm-1.0-2 tag) should make this problem go away
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•