Uploaded image for project: 'CouchDB'
  1. CouchDB
  2. COUCHDB-2947

Applying limit and continuous to _changes results in odd behavior when writing documents during request

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Won't Fix
    • None
    • None
    • Database Core
    • None

    Description

      If I have a database that is continuously receiving updates, applying continuous and limit parameters to my database query gives odd behaviour.

      Take this URL:

      http://localhost:5984/database/_changes?since=0&limit=1&feed=continuous

      If I call this URL while running a script writing documents to the database at a great enough rate that the continuous changes timeout is not hit, the behaviour isn't as I'd expect.

      What I'd expect to happen:

      1 doc is emitted, the _changes feed emits the last_seq line, then the request is terminated.

      What actually happens:

      Once `limit` items have been returned, entries continue being emitted until writing documents to the database stops. After writing stops, entries stop being emitted into the response. If I start writing again, the response starts to emit changes entries again. If I don't start writing again, the request eventually times out via the default setting in couch.ini and emits the last_seq line and closes.

      If a timeout is applied in the URL, this overrides the default timeout as expected, but otherwise the behaviour remains the same.

      To be clear, the feed is emitting the correct stuff – entries in sequence order from the since parameter, and last_seq has the expected value given the items emitted into the response – it's just emitting stuff longer than I'd expect. The _changes feed isn't catching up to the current seq, it's just continuing to emit while the documents are being written. Once writing to the database stops, the request stops emitting changes wherever it's managed to get up to. From what I can tell, the emitted entries into the changes feed are in the right sequence, so we're not missing items from the feed, just emitting too many of them.

      Attachments

        Activity

          People

            Unassigned Unassigned
            mikerhodes Mike Rhodes
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: