I'm bringing this conversation into couchdb-dev in case others are
interested.
-Damien
Begin forwarded message:
From: Damien Katz <[EMAIL PROTECTED]>
Date: October 27, 2008 3:43:15 PM CDT
To: Chris Anderson <[EMAIL PROTECTED]>
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:
http://github.com/jchris/couchdb/tree/update-false
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 <[EMAIL PROTECTED]>
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
http://jchris.mfdz.com
--
Chris Anderson
http://jchris.mfdz.com
<upfalse.diff>
