CouchDB
  1. CouchDB
  2. COUCHDB-644

Replicator creates URLs which are too long for the source node

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Duplicate
    • Affects Version/s: 0.9
    • Fix Version/s: 1.0.3, 1.1
    • Component/s: Replication
    • Labels:
      None
    • Environment:

      couchdb 0.9.0.r766883 CentOS x86_64

    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      We have an environment which can on ocassion create many open revs of a doc. The URLs that the replicator creates are longer than the http://issues.apache.org/jira/browse/COUCHDB-243 "mochiweb has an 8k limit", resulting in a general server crash.

      To date the only work-around identified is to "export" the latest revisions of all docs in the database, destroy the database, re-create the database and reload the exported documents.

      On one of our environments we have:
      These docs have the trouble:

      Their requests length - path + params (ie no host:port) are shown here (the key) with the number of times that that length was seen in our log files (the count):

      key => count
      8544 => 24
      8557 => 11
      8568 => 2392
      8572 => 55
      8591 => 893
      8594 => 45
      8636 => 27

      Attached is a file with a sample of these too-long URLs.

      1. urls.too.long.100
        854 kB
        Enda Farrell

        Issue Links

          Activity

          Hide
          Rachel Willmer added a comment -

          Increasing the buffer size solves the problem in the short term; but a better solution will be to figure out the couchdb code doesn't split the request into multiples, as suggested by Adam above.

          I'll see whether my nascent erlang skills are good enough to figure it out.

          Show
          Rachel Willmer added a comment - Increasing the buffer size solves the problem in the short term; but a better solution will be to figure out the couchdb code doesn't split the request into multiples, as suggested by Adam above. I'll see whether my nascent erlang skills are good enough to figure it out.
          Hide
          Rachel Willmer added a comment -

          Copious quantities of io:format statements and strong coffee have led me to believe that the underlying problem is the default receive buffer size (8k) in erlang.

          An incoming packet larger than this causes an exception in mochiweb_http.erl:request, which then closes the socket and exits.

          You can fix it in mochiweb_http.erl by adding

          {recbuf, 16384}

          (or whatever limit you want) to the call to inet:setopts in loop().

          Rachel

          Show
          Rachel Willmer added a comment - Copious quantities of io:format statements and strong coffee have led me to believe that the underlying problem is the default receive buffer size (8k) in erlang. An incoming packet larger than this causes an exception in mochiweb_http.erl:request, which then closes the socket and exits. You can fix it in mochiweb_http.erl by adding {recbuf, 16384} (or whatever limit you want) to the call to inet:setopts in loop(). Rachel
          Hide
          Adam Kocoloski added a comment -

          Hi Enda, thanks for the report. It is a little surprising, since 0.9.0 contains code to split a request into multiple requests if the revision list is too long. Perhaps I got the calculation wrong at the time.

          Show
          Adam Kocoloski added a comment - Hi Enda, thanks for the report. It is a little surprising, since 0.9.0 contains code to split a request into multiple requests if the revision list is too long. Perhaps I got the calculation wrong at the time.
          Hide
          Enda Farrell added a comment - - edited

          No extra info/detail is logged in debug.

          Show
          Enda Farrell added a comment - - edited No extra info/detail is logged in debug.
          Hide
          Enda Farrell added a comment -

          "retrying couch_rep HTTP get request due to

          {error, connection_closed}

          "

          this is the only extra info that logging at INFO gives.

          Show
          Enda Farrell added a comment - "retrying couch_rep HTTP get request due to {error, connection_closed} " this is the only extra info that logging at INFO gives.
          Hide
          Enda Farrell added a comment -

          http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_request.erl as of 9 Feb 2010 shows that this URL length restriction is still current. The COUCHDB-243 bug was resolved as "won't fix, not a limit in couchdb" which would seem to agree

          Show
          Enda Farrell added a comment - http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_request.erl as of 9 Feb 2010 shows that this URL length restriction is still current. The COUCHDB-243 bug was resolved as "won't fix, not a limit in couchdb" which would seem to agree
          Hide
          Enda Farrell added a comment -

          Attached is a sample of 100 URLs which when created were too long.

          As our logging is set to ERROR only (due to https://issues.apache.org/jira/browse/COUCHDB-412) we cannot see the source instance's logs (we use pull replication)

          Show
          Enda Farrell added a comment - Attached is a sample of 100 URLs which when created were too long. As our logging is set to ERROR only (due to https://issues.apache.org/jira/browse/COUCHDB-412 ) we cannot see the source instance's logs (we use pull replication)

            People

            • Assignee:
              Unassigned
              Reporter:
              Enda Farrell
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development