incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: deleted database while longpolling _changes
Date Tue, 20 Nov 2012 23:25:03 GMT
We close pending changes feeds when the db is deleted, that's all. If you
had updated the db, you'd had seen the update, but the next thing that
happened after the _changes call was the delete.

You can check the instance_start_time of the database, it will change if
the db is deleted and recreated. That said, the way that the replicator
detects this situation is stronger, it creates a _local doc which records
the since value it should use next time. A delete/recreate will delete this
document, and so the replicator knows to start at 0.


On 20 November 2012 23:03, Cliffano Subagio <cliffano@gmail.com> wrote:

> "No, you'll get the same result on a timeout."
>
> Does that mean that the empty results after the database deletion is also
> caused by a timeout?
>
> "You can't determine last_seq using the _changes feed, given the above, but
> the correct value is reported as update_seq in the result of GET /dbname."
>
> Let's say the client is longpolling _changes feed with 'since' parameter
> 500.
> The database is deleted then recreated,
> (a) the client gets a response with last_seq 500, while GET /dbname
> update_seq is 0
> (b) three documents are then added to the database within a short period of
> time (there are other clients writing to the database).
>
> The client needs to reset 'since' parameter because the database's last
> sequence is no longer 500, but when it sends a request GET /dbname
> update_seq, the update_seq is already 3, which means the client misses out
> 3 changes between (a) and (b).
> Another option is to reset 'since' parameter to 0, but this is not good
> when the empty results is caused by a legitimate timeout and not a database
> deletion, the client needs to rescan the changes from the beginning.
>
> What would be the correct way to determine the next 'since' parameter value
> since last_seq and update_seq can't be used in above situation?
>
>
> On Tue, Nov 20, 2012 at 7:45 PM, Robert Newson <rnewson@apache.org> wrote:
>
> > "Can the empty results array be used to identify that the database was
> > deleted?"
> >
> > No, you'll get the same result on a timeout.
> >
> > "What is the reasoning behind returning since parameter value 123 instead
> > of the real last_seq 0?"
> >
> > That does look wrong at first glance but it's because we start reading
> the
> > internal by_seq view at the since value, the last_seq value is reported
> as
> > the final key we iterate over, so by sending a key greater than the end
> of
> > the database (something the primary consumer of _changes feeds, the
> > replicator, would never do) we find no rows, terminating immediately, but
> > reporting the last_seq value we have. We could probably fix that but it
> > sounds a little fiddly.
> >
> > You can't determine last_seq using the _changes feed, given the above,
> but
> > the correct value is reported as update_seq in the result of GET /dbname.
> >
> > B.
> >
> >
> >
> >
> > On 20 November 2012 08:27, Cliffano Subagio <cliffano@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I have a database which _changes notification is being longpolled.
> > > I notice that when I delete this database, the response body will have
> > > results containing an empty array, along with a last_seq property, and
> > > status code 200.
> > >
> > > Can the empty results array be used to identify that the database was
> > > deleted?
> > > Is there any other events that might result in an empty results array?
> > >
> > >
> > > Another thing I'm curious about is the last_seq property value.
> > > I created a new database, query dbname/_changes, it return last_seq 0
> as
> > > expected
> > >
> > > {"results":[
> > >
> > > ],
> > > "last_seq":0}
> > >
> > > But when I query dbname/_changes?heartbeat=1000&feed=longpoll&since=123
> > > I get the since parameter value as last_seq property value, like this
> > >
> > > {"results":[
> > > ...<newlines here>
> > > ],
> > > "last_seq":123}
> > >
> > > What is the reasoning behind returning since parameter value 123
> instead
> > of
> > > the real last_seq 0?
> > > Just by checking the response body, how to determine whether last_seq
> 123
> > > is really the number of changes in the database? or if 123 is only
> since
> > > parameter value?
> > >
> > >
> > > Cheers,
> > > Cliff.
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message