couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Second call for objections releasing 0.10
Date Mon, 21 Sep 2009 21:03:38 GMT
On Sep 21, 2009, at 1:08 AM, Benoit Chesneau wrote:

> On Sun, Sep 20, 2009 at 11:48 PM, Chris Anderson
>> That's the sort of thing that'd get backported for 0.10.1 anyway,  
>> so I
>> don't think it's a blocker. Also, probably a fairly easy patch.
>>
>> Chris
>>
> Well it's really annoying to have such error in logs when you are in
> production. I've also updated the bug : when you delete a db witch is
> continuously replicatedit create an error too on the machine handling
> replication when I delete a database on source. There maybe other side
> effect.

So, we fixed a couple of bugs affecting _changes when a DB is deleted  
mid-response, but it's not perfect.  In particular:

1) There's no indication to the end user that _changes terminated  
because the DB was deleted.  Benoit wrote up such a patch in  
COUCHDB-508, but I didn't want to alter the _changes format so close  
to the release.

2) The replicator may still puke out quite a bit of Erlang tracebacks  
if you delete a DB that is currently a replication source or target.   
I think some of it is unavoidable -- deleting a DB out from underneath  
a replication should be a rare occurrence, and for those rare  
occurrences it makes sense to use exit codes other than "normal" so  
that other related processes are also terminated.  When we do that,  
tracebacks are the immediate result.  With that said, we can still  
slim down what's in place now and avoid some duplication of error  
messages.  I don't think that goal should hold up 0.10.

Best, Adam

Mime
View raw message