couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Fwd: near view state server success
Date Mon, 27 Oct 2008 21:31:20 GMT
I'm bringing this conversation into couchdb-dev in case others are  


Begin forwarded message:

> From: Damien Katz <>
> Date: October 27, 2008 3:43:15 PM CDT
> To: Chris Anderson <>
> Subject: Re: near view state server success
> Overall this looks goo,d but it looks you've gone down a little bit  
> of a wrong path withe purge_seq nums. The "clients" should only be  
> sending update seq nums in the get_updated messages, and the  
> view_group servers should never worry about the purge_seq_nums  
> stuff, only the updater process worries about it, and for now, don't  
> worry about it at all.
> I understand what you are saying about the gen_server stuff and  
> resending the client message. I dug down in the the gen_server code,  
> and found how to send the right message to yourself, but I think  
> it's a bad idea as it relies on under-documented things that maybe  
> could change. I think the best options is to switch to gen_server  
> and have it send a "resend" response to the client, and the client  
> resends the message.
> The seperate SpawnFun and SpawnArgs isn't necessary, because you can  
> use a closure to get the spawn and create the custom function:
> SpawnArgs = Foo(),
> SpawnFun  = fun () -> do_spawn(SpawnArgs) end,
> Finally I think the initial update seq num in the couch_view_group  
> server should be -1, instead of 0. That way, when the no_update  
> client asks for the group object, you won't return him a nil if the  
> updater process hasn't returned yet. Once the updater returns an  
> intial group, it will have a seq_num of 0 or greater.
> -Damien
> On Oct 24, 2008, at 9:25 PM, Chris Anderson wrote:
>> Damien,
>> Here's the latest progress on the update=false patch.
>> I've attached the diff, but you can also access the repository here:
>> I stopped short of converting to gen_server, because I think I don't
>> understand gen_server well enough to see how to replace
>> couch_view_group:server_loop with a gen_server. It relies on  
>> resending
>> itself the same message it just received, and the
>> couch_view:get_updated_group is synchronous, but the server_loop is
>> asynchronous.
>> I attempted to pass the purge_seq into couch_view_group, and setup
>> guards so that it would only return view indexes who's SeqId and
>> PurgeSeq were both greater than or equal to the database at request
>> time. All the tests still pass, except purge, which hangs now instead
>> of failing.
>> The reason seems to be that purging can make the database's update
>> sequence move backwards (based on what I'm getting in my debug logs).
>> Is that possible, or am I reading it wrong?
>> If purge can move the sequence number down, then couch_view_group  
>> (and
>> not just couch_view_updater) will need to know about the +1 purge vs
>> more than one purge differences issue, so it can invalidate indexes
>> it's hanging onto.
>> I've got time to work on this again, so I hope I can finish it in the
>> next few weeks. Any advice you have is appreciated.
>> Chris
>> On Wed, Oct 8, 2008 at 2:51 AM, Chris Anderson <>  
>> wrote:
>>> Damien,
>>> I'm fairly certain I'm on the right track now. All the tests are
>>> passing, except for purge. My guess is that purging doesn't  
>>> increment
>>> the database's seq_id. We can probably treat purge_seq_id like  
>>> seq_id,
>>> in the guard clauses. I wanted to make sure I'm in the right  
>>> ballpark
>>> before I start to polish this code.
>>> To that end, the whitespace is a mess, and I haven't tested
>>> update=false (I'm fairly certain it will work). I'll definitely want
>>> to clean this up before I commit it, but I'd like to get a thumbs up
>>> from you before I put the time into polishing it.
>>> Chris
>>> --
>>> Chris Anderson
>> -- 
>> Chris Anderson
>> <upfalse.diff>

View raw message