Re: Compaction of a database with the same number of documents is getting slower over time

To first order it shouldn't be the case. Is the number of deleted documents growing with time? That'd have an impact. Adam > On Apr 22, 2014, at 8:06 AM, Boaz Citrin wrote: > > Hello, > > Our database contains more or less the same number of documents, however > the documents themselves chang

Re: Reseting DB Sequence Number

Hi Behrad, no, there's no way to reset that sequence number. How many deleted docs do you have in your DB? Is the aim behind your question to avoid sending those deleted docs through the view generation process? Note that the actual number of entries in the index is going to be significantly

Re: Replication vs. Compaction

On Feb 18, 2014, at 11:38 AM, Jan Lehnardt wrote: > On 31 Jan 2014, at 20:08 , Jason Smith wrote: > >> However there is a pathological situation where you are >> updating faster than the compactor can run, and you will get an infinite >> loop (plus very heavy i/o and filesystem waste as the com

Re: Replication vs. Compaction

On Jan 31, 2014, at 3:43 PM, Jens Alfke wrote: > On Jan 31, 2014, at 12:07 PM, Boaz Citrin wrote: > >> But if replication only copies the leaf then it makes sense that it is >> fatser, at least on the same machine. Instead of balancing a tree it just >> copies a single revision. > > Um, no. Th

Re: Revisions lost on CouchDB 1.2.0

On Jan 31, 2014, at 6:36 PM, Luca Morandini wrote: > On 31/01/14 19:42, Robert Samuel Newson wrote: >> >> As Simon says, this is the normal and expected behavior of CouchDB after >> database compaction (or replication). CouchDB is not a revision control >> system, >> it only keeps the latest ve

Re: Replication of attachment is extremely slow.. LOGGED INFORMATION

Well how about that. Go Nick! Adam > On Jan 24, 2014, at 7:31 PM, Paul Davis wrote: > > Interesting note, this is fixed by applying the patch to COUCHDB-1953. > >> On Fri, Jan 24, 2014 at 3:03 PM, Rian R. Maloney >> wrote: >> Will do Dave. Thanks again for the help >> >> Im away from desk a

Re: Clarification on "UUIDs Configuration"

On Jan 20, 2014, at 3:36 PM, Jens Alfke wrote: > > On Jan 20, 2014, at 12:19 PM, Stefan Klein wrote: > >> a performance impact of random document ids. >> If the document ids are not sequential larger portions of the b-tree need >> to be rewriten. >> Is this related only to inserts or also to u

Re: Errors when trying to compact

Hi Vladimir, compaction is an asynchronous process and so only a small subset of the possible errors that could occur during a compaction will surface in time to be reported as part of the response to your POST request. Adam On Jan 20, 2014, at 5:05 PM, Vladimir Ralev wrote: > Upgraded to lat

Re: Number of surviving revisions after compaction

On Jan 20, 2014, at 11:29 AM, Vladimir Ralev wrote: > Hello all > > I was reading about _revs_limit > > which > defaults to 1000 or so here > http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Databas

Re: A CouchDB/Cloudant Scale & Authorization question

Hi Andy, you're right that a DB per user-feature is currently the way to go to achieve the kind of access control granularity that you have in mind. 100k databases in a Cloudant account is not all that uncommon. Cheers, Adam On Jan 9, 2014, at 8:55 AM, Andy Dorman wrote: > Hi, we are new to

Re: Timeout using Erlang views with large documents

Hey folks, back to the original question, the native process gen_server respects the timeout internally but the public API in the module still makes a gen_server:call with the default 5 second timeout: https://github.com/apache/couchdb/blob/1.5.0/src/couchdb/couch_native_process.erl#L62-L63 Con

Re: Doc Not Restored After PURGE

, 2013, at 6:07 PM, Jay Clark wrote: > What about if a COMPACT were performed on theTarget before replicating again > from theSource? Does that affect replication and which docs get checked? > > > ~Jay > > > > Original message ---- > From Adam Kocolos

Re: Doc Not Restored After PURGE

a DELETE, but I thought _purge was supposed > to make the database as if the doc was never there? > > --- > www.maf.org/rhoads > www.ontherhoads.org > > > On Wed, Oct 23, 2013 at 3:49 PM, Adam Kocoloski wrote: > >> That's definitely one o

Re: Doc Not Restored After PURGE

That's definitely one of the dangerous bits about purge. If you do a noop update to doc2 on theSource and then replicate it should make its way to theTarget. Adam On Oct 23, 2013, at 5:04 PM, Brad Rhoads wrote: > Say I have two databases, theSource and theTarget, then: > > Add docs 1,2 & 3

Re: What's Better 1 Doc With Many Attachments or Many Docs With 1 Attachment

The initial replication of a document with a very large number of attachments can be expensive -- it's an all-or-nothing affair. After that when you update a single attachment on the doc the replicator is smart enough to just transfer that attachment. Considering only the replicator's perspect

Re: Lots of requests with continuous replications (every 5 seconds)

It's really a bit silly, though -- as far as I can tell the GET requests against the source DB are only used to keep the source_seq information in _active_tasks current. Adam On Aug 29, 2013, at 2:36 PM, Robert Newson wrote: > Hi, > > The checkpoint interval is now configurable on Cloudant (

Re: replication slow down

Did you specify "continuous": true in the replication spec? If you did, do you see the same slowdown if you omit that flag? This sounds rather similar to a bug we encountered in early builds of BigCouch, but I don't remember the history of the codebase well enough to say whether the bug might

Re: distributed map/reduce in BigCouch

was generally curious what the > difference was. > > again..many thanks...I can now go full steam ahead with my project > regards, > > Stanley > > > > > On Sun, Aug 4, 2013 at 10:29 AM, Adam Kocoloski > wrote: > >> The 'q' value is th

Re: distributed map/reduce in BigCouch

The 'q' value is the number of unique shards that comprise the single logical database. BigCouch will keep 'n' replicas of each shard, so in total a database will have q*n .couch files associated with it. The number of nodes in the cluster is an independent concern; BigCouch will happily store

Re: Attachment replication

Yes, the system provides that guarantee. Some versions of CouchDB transfers the attachments in separate requests, but when the doc is in the target's _changes you can be assured that all of its attachments have made the trip. Cheers, Adam On Aug 3, 2013, at 5:36 PM, Nick North wrote: > If I

Re: Best Choice for redundant production environment?

Hi Dan, oops, sounds like the docs missed a port range there. Each of your nodes is listening for connections from the other nodes on a particular port. That port is advertised by EPMD on 4369. You can control the range of ports that might be used in the vm.args file -- the following directiv

Re: Are pull replications really still faster than push?

On Jun 20, 2013, at 1:32 PM, Jens Alfke wrote: > The wiki documentation of the _replicate API says: > >> As of CouchDB 0.9, pull replication is a lot more efficient and resistant to >> errors, and it is suggested that you use pull replication in most cases, >> especially if your documents are

Re: Large views and concurrent access

The file descriptor process for the .view file is shared by all clients querying the view. I suppose you might be at the limit of what it can deliver from disk, but it's hard to say for certain. The Fd does not do any caching or deduplication of pread requests. I can't think of anything other

Re: large replication URL

Well, a GET request is the RESTful choice. I do admit that the limit on the length of a URL is going to be much more stringent than the limit on the size of a POST body. CouchDB already has code to split the request up if the generated URL is "too large". Currently the value of "too large" is

Re: user Digest 7 Jun 2013 05:13:11 -0000 Issue 1365

Consider yourself flattered ;-) Adam On Jun 8, 2013, at 2:44 AM, Jason Smith wrote: > It was simply a playful jab at hosting companies which moved to a similar > billing model. > > > On Sat, Jun 8, 2013 at 1:37 PM, Zdravko Gligic wrote: > >> "In fact, between you and me, before the Nodejits

Re: virtualizing databases

I discussed COUCHDB-1736 on dev@ the other day and just copied my comment into JIRA. As you observed, an alias system is somewhat akin to a degenerate case of sharding. In BigCouch we store the shard map for each clustered database in a special system database that is local to each node in the

Re: _rev or rev...? Did I see that right?

It's a wart for sure. I still get it wrong from time to time. Adam On May 30, 2013, at 5:00 PM, Scott Weber wrote: > I concur with Mark that it would be a bummer. > > I understand the desire to remove potential conflicts of 'id' and 'rev', > which > is probably why they were 'name mangled'

Re: Speed up Replication with large Database

It's a hack, but if you know the sequence number of the database when you copied it you can add a parameter to the body of the replication specification to "fast-forward" it and bypass the checks: "since_seq": 1234 Adam On May 30, 2013, at 7:01 AM, Robert Newson wrote: > Hi, > > The replica

Re: number of views pe design doc

On May 29, 2013, at 8:56 PM, Stanley Iriele wrote: > On Wed, May 29, 2013 at 5:41 PM, Jens Alfke wrote: > >> >> On May 29, 2013, at 5:23 PM, Stanley Iriele >> wrote: >> >>> I've been using couchdb for a while now and I have had problems in the >> past >>> with having too many views in one d

Re: Timestamp in CouchDB Logs?

We have a ticket for a mod_log_config equivalent that would allow for this (and much more): https://issues.apache.org/jira/browse/COUCHDB-1401 Adam On May 28, 2013, at 4:24 PM, Robert Newson wrote: > Not without a code change; > > log_request(#httpd{mochi_req=MochiReq,peer=Peer}, Code) -> >

Re: View to fetch a list of conversation id's with recent activity

If the number of unique thread_ids in a given result set is not huge you might consider a _list function that suppresses rows where the thread_id matches one that you've already sent out the wire. Adam On Apr 22, 2013, at 8:49 PM, Michael Jackson wrote: > I'm building a messaging app where me

Re: Questions on durability

Hi Mark, answers inline … On Apr 23, 2013, at 3:37 PM, Mark van Cuijk wrote: > Hi, > > For a new project, we're considering CouchDB as an interesting candidate for > storage, mainly because of the good durability properties, support for > replication and the continuous changes feed. > > Reg

Re: replicating docs with tons of conflicts

On Mar 15, 2013, at 1:40 PM, Stephen Bartell wrote: > > On Mar 14, 2013, at 3:36 PM, Robert Newson wrote: > >> Runaway processes are the very devil but the problem is not specific >> to CouchDB, there is no CouchDB mechanism for this just as there's no >> bash/python/ruby/perl method to limit

Re: Documented API does not work.

On Dec 26, 2012, at 11:02 PM, Jens Alfke wrote: > Agreed. This seems to me to be an endemic problem of Erlang programs — the > pattern-matching behavior in the language is extremely convenient but results > in software that handles any sort of incorrect input with a generic exception > like “b

Re: Disable default unsecure plain HTTP 5984

I think that may be the wrong syntax for .ini file comments. Can you try a leading ";" instead? Adam On Dec 11, 2012, at 3:02 PM, Nestor Urquiza wrote: > This is an old thread but the issue is back in version 1.2.0 > > Commenting out the suggested line from default.ini ... > [daemons] > #htt

Re: Please Respond: Proposal to Raise Erlang min version to R13B04 for couchdb 1.3

Thanks Ryan, here's a start … Debian 6.0 : R14A (!) Debian 6.0 backports: R15B01 Ubuntu 10.04 LTS: R13B03 Ubuntu 11.10: R14B02 Ubuntu 12.04 LTS: R14B04 Ubuntu 12.10: R15B01 On Nov 28, 2012, at 5:54 PM, Ryan Ramage wrote: > I was asked by

Re: running out of space

You probably have an empty .compact file for the Chef DB. Remove that file and try again. We fixed this bug in a newer CouchDB release (can't remember which one off the top of my head). Cheers, Adam On Nov 26, 2012, at 12:11 PM, Spike Grobstein wrote: > Hi Robert, > > Wow. You are correct

Re: Does CouchDB support HTTP pipelining?

On Oct 30, 2012, at 4:54 PM, Jens Alfke wrote: > I’m assuming that the ?revisions=true option doesn’t add a huge amount of > overhead, since the revision tree is already contained in the document’s > b-tree node, right? That's correct, no need for an extra disk lookup or anything like that.

Re: eacces error

On Oct 3, 2012, at 10:54 AM, Dave Cottlehuber wrote: > On 3 October 2012 16:49, Adam Kocoloski wrote: >> Yep, that matches up with my experience. >> >> Adam >> >> On Oct 3, 2012, at 10:47 AM, Martin Hewitt wrote: >> >>> This one's fur

Re: eacces error

her error, but the view is generated correctly, and > further view updates do not produce errors. > > Very curious behaviour. > > Martin > > > On Wednesday, 3 October 2012 at 15:44, Adam Kocoloski wrote: > >> This one in particular has always been a bit o

Re: eacces error

This one in particular has always been a bit of a mystery to me. Sometimes it seems to be completely spurious. Adam On Oct 3, 2012, at 8:08 AM, Martin Hewitt wrote: > Hi Dave, > > Thanks for these links, no luck on my current install, but I may scrub down > and start again, as I can't real

Re: following fast doc updates

On Sep 24, 2012, at 5:16 PM, Mark Hahn wrote: > If I update a particular doc multiple times rapidly, is each update > guaranteed to show up in a continuous changes feed? I am worried that the > change feed will be optimized to just show the latest value of a doc with > multiple updates. This wo

Re: Multiple authentication DBs

Certainly, that would work, but I'm not sure what the OP was trying to accomplish by the separation in the first place. Adam On Sep 21, 2012, at 9:42 AM, Keith Gable wrote: > Couldn't you technically replicate the other DB into the main one? > On Sep 21, 2012 8:11 AM, "A

Re: Multiple authentication DBs

On Sep 20, 2012, at 6:48 AM, Ramkrishna Kulkarni wrote: > Hello, > > Is it possible to set multiple DBs as authentication DBs? Or some other way > where I can use two different DBs for authentication instead of what is > specified in "authentication_db". > > Thanks, > Ram Nope, sorry. Regard

Re: Summary view for Pie Charting

On Sep 20, 2012, at 8:00 AM, Matthieu Rakotojaona wrote: > This raises a question I do not know the answer for : when we use such > a _list function, are we sure we will not take into account a doc that > will be added/modified _after_ having launched the function ? That's correct, it will not.

Re: max_document_size limits on hosted services?

We have the maximum size set smaller at Cloudant, but certainly well above the 200 KB you mention here. I'm not aware of other more restrictive limits in our setup (and I'm certain multi-MB uploads work in the general case). Cheers, Adam On Aug 27, 2012, at 8:24 PM, Jens Alfke wrote: > I've

Re: JavaScript 1.8.5 and Upgrades

On Aug 15, 2012, at 9:32 AM, Will Heger wrote: > After pushing some UTC Date() containing reduce code to a server, I > discovered that the server was using 1.8.0 SpiderMonkey rather than > 1.8.5, balls! > > So, my impression from the docs is that CouchDB needs to be compiled > with a JavaScript e

Re: BigCouch returns compressed attachments without indicating they're compressed

On May 17, 2012, at 10:05 PM, Adam Kocoloski wrote: > On May 17, 2012, at 9:50 PM, Jens Alfke wrote: > >> FYI, the person who reported this issue to me was running a CouchDB 1.0 >> server, not BigCouch. He says it went away after he upgraded to CouchDB 1.2. >>

Re: How does OAuth support, or custom headers, work in the replicator?

On May 18, 2012, at 8:54 PM, Jens Alfke wrote: > There's a small bit in the wiki* that hints at a replication JSON parameter > to set custom headers. One of the examples of a _replicate request shows the > body: > >> {"source":{"url":"https://example.net:5984/db","headers":{"Authorization":"Bas

Re: Performance decrease from 1.0.1 to 1.2.0

ure, there is a good reason for enabling that algorithm? > > > On 18.05.2012 22:27, Adam Kocoloski wrote: >> 40ms indicates Nagle's algorithm is kicking in and trying to reduce >> the number of packets sent over the wire. Try setting the >> following in the .ini co

Re: Performance decrease from 1.0.1 to 1.2.0

40ms indicates Nagle's algorithm is kicking in and trying to reduce the number of packets sent over the wire. Try setting the following in the .ini configuration: socket_options = [{nodelay, true}] I believe that was the default in 1.0 and has changed since then. Cheers, Adam On May 18, 2012

Re: BigCouch returns compressed attachments without indicating they're compressed

On May 17, 2012, at 9:50 PM, Jens Alfke wrote: > FYI, the person who reported this issue to me was running a CouchDB 1.0 > server, not BigCouch. He says it went away after he upgraded to CouchDB 1.2. > > That implies that the 'encoding' and 'encoded_length' attachment properties > got added aft

Re: Continuous-mode _changes feed without chunked encoding?

As far as I'm concerned the only reason for the chunked encoding is because we have no idea about the Conent-Length. If content-length: 999 is really an acceptable option I don't think there are any other blockers to offering an optional non-chunked encoding. Adam On May 1, 2012, at 1

Re: CouchDB slow response times

ning won't give anything serious > over multiple persistent connections (and no pipelining on them)? > (I've measured non persistent and persistent: 1700 QPS vs 2200, each of them > gave 100% CPU usage from CouchDB) > > On 04/20/12 17:55, Adam Kocoloski wrote: >>

Re: CouchDB slow response times

Hi Attila, I assume you have your reasons for limiting CouchDB to one core, but you should be able to improve concurrent read performance by leveraging a few more of those cores on your server. This is Erlang, after all ;-) I've seen BigCouch nodes pretty nearly saturate Dual X5670s given enou

Re: Making conflicts first class citizens

On Apr 18, 2012, at 4:51 AM, Paul Hirst wrote: > I saw this idea on allourideas.org: > > "Conflicts as first class citizens: Surface the conflict on read, and always > accept a write, assuming it passes validation." > > I was wondering if anyone could expand on this? > > On write, conflicts wi

Re: When will BigCouch be merged into Apache Couchdb?

> Is BigCouch going to be an optional clustering component/plugin piece? > > -- > Sean Copenhaver > > > On Monday, April 2, 2012 at 10:32 AM, Adam Kocoloski wrote: > >> On Apr 2, 2012, at 10:28 AM, Mike Kimber wrote: >> >>> Can anyone able to prov

Re: When will BigCouch be merged into Apache Couchdb?

On Apr 2, 2012, at 10:28 AM, Mike Kimber wrote: > Can anyone able to provide an ETA as to when BigCouch be merged into Apache > Couchdb? > > Or if not provide any idea what the migration might be from BigCouch to the > merged code base? > > Juts trying to worm out if I should wait for the code

Re: Introducing Iron Cushion, a benchmark and load test for CouchDB

On Mar 31, 2012, at 2:42 PM, Michael Parker wrote: > Hi all, > > Last week I searched for CouchDB benchmark and load testing suites. I > only came up with three-year old blog posts containing one-off scripts > or tests for read performance using ab, and the Definitive Guide > itself (http://guide

Re: Size of couchdb documents

On Mar 15, 2012, at 7:55 PM, Jason Smith wrote: > On Thu, Mar 15, 2012 at 10:14 PM, Daniel Gonzalez > wrote: >> Hi Matthieu, >> >> This really seems to help. I am using now a base62 encoded monotonically >> increasing integer, which means my doc_id goes from "0" onwards, using the >> alphabet:

Re: wiki edit on built-in reduce functions

On Jan 17, 2012, at 8:31 PM, James Marca wrote: > Hi, > > this is a quick note for whomever is in charge of the wiki (my wiki > account no longer has write ability) > > Built-In_Reduce_Functions says that you need to emit numbers for the > _sum operation. As of 1.2.x, this can also be a list o

Re: The Future

On Jan 6, 2012, at 4:27 PM, Jan Lehnardt wrote: > > On Jan 6, 2012, at 22:21 , Jim Jagielski wrote: > >> It might not be a bad idea to maybe blog something about this... >> Certainly the story being presented to the unwashed masses >> is that Damien is still the driving force behind CouchDB, >>

Re: The Future

Hi Jim, I did my best to offer a competing narrative over at http://blog.cloudant.com/the-future-of-couchdb/. Cheers, Adam On Jan 6, 2012, at 4:21 PM, Jim Jagielski wrote: > It might not be a bad idea to maybe blog something about this... > Certainly the story being presented to the unwashed m

Re: [ANN]: Dave Cottlehuber elected CouchDB committer

Great news! A+ Adam On Jan 6, 2012, at 4:15 PM, Jan Lehnardt wrote: > Hey all, > > I am happy to report that the CouchDB PMC has elected > Dave Cottlehuber to become a CouchDB committer. > > His election recognises his outstanding contributions to > the Windows build system and other parts of

Re: The Future

Hi Mikeal, I don't see how you can write this with a straight face in response to Noah's mail. I thought it was a stellar example of project leadership. - Yes, we've talked about redoing the website before. It needs to be done, we're going to do it. - Yes, the release schedule has slowed sinc

Re: CouchBase discontinues Single Server: now what?

Hi Jason, it's definitely under consideration, see http://mail-archives.apache.org/mod_mbox/couchdb-dev/20.mbox/%3c785fabdb-2ef0-409a-a6c5-e9c8d4982...@apache.org%3E Regards, Adam On Jan 4, 2012, at 10:08 AM, Jason Sachs wrote: > CouchBase just recently announced that they were discontinuin

Re: Delete replication history

On Jan 3, 2012, at 10:41 AM, Filipe David Manana wrote: > On Tue, Jan 3, 2012 at 3:00 PM, Adam Kocoloski wrote: >> On Jan 3, 2012, at 3:23 AM, Paul Hirst wrote: >> >>>> -Original Message- >>>> From: Robert Newson [mailto:rnew...@apache.org] &g

Re: Delete replication history

On Jan 3, 2012, at 3:23 AM, Paul Hirst wrote: >> -Original Message- >> From: Robert Newson [mailto:rnew...@apache.org] >> Sent: 24 December 2011 12:46 >> To: user@couchdb.apache.org >> Subject: Re: Delete replication history >> >> I believe Jim is referring to the replication checkpoint d

Re: Interpreting status of replication from BigCouch

tforward to implement binary_to_term. (Patches welcome!) > > https://github.com/iriscouch/erlang.js > > The key table is this: > https://github.com/iriscouch/erlang.js/blob/master/lib.js#L1-26 > > On Wed, Nov 30, 2011 at 9:06 AM, Adam Kocoloski wrote: >> Hi Jens, y

Re: Interpreting status of replication from BigCouch

Hi Jens, you're certainly right about the format being subject to change -- in BigCouch's master branch it's [3264, "g1AAA..."] to allow for sane sorting of the sequences. Just an FYI. The hex portion of the sequence is a Base64-encoded term_to_binary representation of a covering set of shards

Re: View row with doc==null

You almost certainly had a view with duplicates (caused by e.g. COUCHDB-968 or COUCHDB-1265). When you deleted the document it left some orphaned rows in the view. Unfortunately, the only way to remove them at present is to compact the database and then rebuild the view from scratch. To dev@:

Re: Conflicting password-storage info on the wiki

On Nov 10, 2011, at 5:00 PM, Jens Alfke wrote: > According to the wiki[1], the documents in the _users database store hashed > passwords in “password_sha” and “salt” attributes. But when I look at my > actual running server, _users documents don’t have those fields in them, just > “name”, “type

Re: replicate A => B, but only docs that exist in B

On Nov 6, 2011, at 8:19 PM, Dave Cottlehuber wrote: > On 6 November 2011 14:14, Gregor Martynus wrote: >> *SCENARIO*: >> >> Each user has its own DB ("B") of documents which replicates continuously >> to a center DB ("A") which contains all documents from all users. That >> works perfectly fine

Re: High latency (40ms) and low request rate (10 rps) under windows

On Oct 25, 2011, at 11:16 PM, Mark Hahn wrote: >> Isn't couchdb crash-proof due to append-only writing? > > Does anyone know for sure about this? I have used append-only files for > many years and have never seen any corruption. I would assume writes happen > in sequence. If the trailer is mis

Re: undefined reference to JS_SealObject

If you have a way to get the official SM 1.8.5 build I'd use that. Spidermonkey builds newer than 1.8.5 definitely will not work without some major changes to the way CouchDB works. Note that "1.9.2" is an xulrunner version which corresponds to something like ~1.8.0. It's not actually newer

Re: undefined reference to JS_SealObject

> On 10/24/2011 04:47 PM, Adam Kocoloski wrote: >> Ugh, that's really not good. What version of CouchDB were you using? >> >> Adam >> >> On Oct 24, 2011, at 10:38 AM, CGS wrote: >> >>> I remember I installed CouchDB using Spidermonkey from &

Re: undefined reference to JS_SealObject

e official version 1.8.5 raised similar error in CouchDB compilation. Maybe > it will help you as well. > > Cheers, > CGS > > > > > On 10/24/2011 04:00 PM, Adam Kocoloski wrote: >> Hi Jim, thanks for the reminder to update the instructions, 1.8.5 is >>

Re: undefined reference to JS_SealObject

Hi Jim, thanks for the reminder to update the instructions, 1.8.5 is definitely preferred now. Paul wrote most of the current logic to compile couchjs against various versions of Spidermonkey in both CouchDB and BigCouch. I don't know if he tried the Ubuntu 11.10 package specifically. I suspe

Re: CouchDB Replication lacking resilience for many database

On Oct 10, 2011, at 8:02 PM, Chris Stockton wrote: > Hello, > > On Mon, Oct 10, 2011 at 4:19 PM, Filipe David Manana > wrote: >> On Tue, Oct 11, 2011 at 12:03 AM, Chris Stockton >> wrote: >> Chris, >> >> That said work is in the'1.2.x' branch (and master). >> CouchDB recently migrated from SVN

Re: "%2F" problems

Hi Kevin, there are a few possibilities, one of which is that the replicator gets confused about the expected length of the response body. My recollection is that the replicator in 1.0.x and 1.1.x ignores the actual value of the content-length header when pulling an attachment and instead expect

Re: CouchDB Crash report db_not_found when attempting to replicate databases

On Wednesday, September 14, 2011 at 3:51 PM, Randall Leeds wrote: > On Wed, Sep 14, 2011 at 12:19, Adam Kocoloski (mailto:adam.kocolo...@gmail.com)>wrote: > > > There's a multipart API which allows for a single PUT request containing > > the document body as JSON and al

Re: Even more fine-grained ETag support when querying views?

It's a decent idea, though it would cause unnecessary cache invalidations in the case of document updates that do not end up changing the emitted KVs for the document. On Thursday, September 15, 2011 at 10:51 AM, sleepnova wrote: > How about max update sequence of current view range? > > 2011/

Re: CouchDB Crash report db_not_found when attempting to replicate databases

. > > It's probably a huge JSON operation and it sucks, but I don't have to parse > it in node.js, I just pipe() the body right along. > > -Mikeal > > On Sep 14, 2011, at September 14, 20118:42 AM, Adam Kocoloski wrote: > > > Hi Mikeal, I just took a quick peek

Re: CouchDB Crash report db_not_found when attempting to replicate databases

Hi Mikeal, I just took a quick peek at your code. It looks like you handle attachments by inlining all of them into the JSON representation of the document. Does that ever cause problems when dealing with the ~100 MB attachments in the npm repo? I've certainly seen my fair share of problems wit

Re: MochiWeb, acceptor pool sizes and handoffs

ptember 14, 2011 at 10:54 AM, Adam Kocoloski wrote: > Hi Martin, iirc the default acceptor pool size is 16. > > Here's how the pool works: those 16 processes are all competing to accept() a > new connection on the socket. When one of them succeeds it executes CouchDB's > H

Re: MochiWeb, acceptor pool sizes and handoffs

Hi Martin, iirc the default acceptor pool size is 16. Here's how the pool works: those 16 processes are all competing to accept() a new connection on the socket. When one of them succeeds it executes CouchDB's HTTP code and is replaced by a newly-spawned process in the pool. The process now exe

Re: What's the best way to jack up the rev number?

On Aug 22, 2011, at 5:03 AM, Jason Smith wrote: > I think also that BigCouch changes the _rev values. Nope, it changes the update_seq of a database, because an integer isn't capable of representing all the details of the current state of the database shards. The document representation stays t

Re: Multi node topology

Hi Robert, no, I wouldn't say that. The projects Paul mentioned can simplify some of the setup of a multi-master deployment even if you don't take advantage of the sharding, but they're by no means required for it. To answer your questions, push and pull replications are approximately equal in

Re: to CouchApp or not to CouchApp

On Aug 16, 2011, at 10:47 PM, Jason Smith wrote: > On Wed, Aug 17, 2011 at 12:55 AM, Jens Alfke wrote: >> IMHO the best behavior is: >> >> - CouchDB intrinsically returns a 401, with the required WWW-Authenticate >> header. That is the correct HTTP behavior when the client is trying to >> acce

Re: Compact not completing

ards > Simon > > ps: updated script attached > > > Am Donnerstag, den 11.08.2011, 12:30 -0400 schrieb Adam Kocoloski: >> Hi Simon, I wouldn't skip the deleted documents, a deleted doc could just as >> easily be the one missing in the ID index. When you lookup a

Re: CouchDB performance

Hi John, first thing I'd point out is that Filipe and Paul have done quite a lot of work on the JSON processor since 1.0.2 was released. Trunk contains a JSON processor that calls out to YAJL instead of relying on pure Erlang code. The improvement for large document bodies is pretty substantia

Re: Compact not completing

gt; > Thank you and best regards > Simon > > > ps: The script i have been using is attached. > > > > Am Dienstag, den 09.08.2011, 16:10 -0400 schrieb Adam Kocoloski: >> Hi Simon, CouchDB 1.1.0 includes a recent optimization to >> _changes?include_d

Re: Compact not completing

Thus it its daily purged and compacted. > > So - the changes feed is of no help. Any other idea? > > Thank you and best regards > Simon > > Am Montag, den 08.08.2011, 13:25 -0400 schrieb Adam Kocoloski: >> Hi Simon, I think my amended instructions to Mike are still a

Re: Compact not completing

Hi Simon, I think my amended instructions to Mike are still a sensible way to debug/workaround the problem. Reiterating (96282148 was the last seq Mike observed in the Futon status for the compaction): > 1) What you really want are the last 1000 Ids in the seq_tree prior to the > compactor cra

Re: Frugal Erlang vs Resources Hungry CouchDB

On Jul 1, 2011, at 11:23 AM, Jens Alfke wrote: > I am not sure whether the db looks up older revisions of documents by > starting from an earlier header (“going back in time”); I don’t think so, > because this would be inefficient (O(N)) for finding a specific revision of a > document. Instead

Re: Data loss in CouchDB 1.0.1

updated. We take reports of this nature quite seriously and will be watching this thread closely. Regards, -- Adam Kocoloski

Re: Spontaneous view rebuild after view compaction?

Hi Paul, I think you're referring to https://issues.apache.org/jira/browse/COUCHDB-994 Adam On Apr 14, 2011, at 8:13 AM, Cory Zue wrote: > Hi Paul, > > I encountered a similar issue with my largest view, but it was > rebuilding whenever couch restarted. I didn't tie it to compaction > because

Re: [ann] refuge couchdb distribution

On Apr 3, 2011, at 10:21 AM, Benoit Chesneau wrote: > On Fri, Apr 1, 2011 at 6:54 PM, Adam Kocoloski wrote: >> Hi Benoit, thanks. This looks like some very developer-friendly packaging. >> Given that CouchDB 1.2 is not a thing yet, perhaps you ought to be reporting >>

Re: [ann] refuge couchdb distribution

Hi Benoit, thanks. This looks like some very developer-friendly packaging. Given that CouchDB 1.2 is not a thing yet, perhaps you ought to be reporting a `git-describe` or something similar for the version? Best, Adam On Apr 1, 2011, at 11:56 AM, Benoit Chesneau wrote: > Hi all, > > While

Re: Views & design documents

On Mar 8, 2011, at 6:27 AM, Martin Hewitt wrote: > Hi all, > > Just a quick question, if I have 5 views in one design doc, and request one > of those views, and the requested view requires a rebuild, will CouchDB > rebuild all 5 views in the document or just the one that was requested? > > Tha

<    1   2   3   4   5   >