I can access /db_name/_all_docs?count=1 fine, actually /db_name/_all_docs is fine and super quick. The URLs as IDs I can see are all properly stored and returned.
When storing, I made sure to use URLEncoder(String, "utf-8") (Java). Perhaps could it be the javascript faulting on the map functions, failing on the URL/ID somehow? scratch that, just tested a view function that doesn't emit a URL/ID, still fails. maybe it's still accessed in processing the view since it is an ID? What is also weird is that beam.smp spikes to 100% after first requesting the view, and doesn't return to normal for about 90 minutes. Everything seems fine except the view it seems. the log, from turning on debug, has: [debug] [<0.49.0>] Spawning new update process for view group _design/standard in database news. [debug] [<0.73.0>] Reseting group index "_design/standard" in db news and nothing else useful I think (other than HTTP headers). Thanks for continuing to help! Will On Thu, Sep 11, 2008 at 6:05 PM, Paul Davis <[EMAIL PROTECTED]>wrote: > 1. Database looks not too big to cause problems > 2. The couchjs process won't start until its first needed. And it'll > stick around after it has been spawned for reuse. Not popping up when > accessing the view is bad. > 3. Good. > 4. Haven't groked the complete workings of the view generation, but > hazarding a guess, it might not get created until the first doc is > returned from the view process. > > The URL vs auto generated ID could be the culprit here. When you > submit docs, are you making sure to properly escape the urls? Does > futon work to view the database? (alternatively, can you get docs from > http://localhost:5984/db_name/_all_docs?count=1) > > Next on the list: > > 1. Change the log level to debug in your couch.ini and see if anything pops > up. > > Paul > > On Thu, Sep 11, 2008 at 5:32 PM, william kinney > <[EMAIL PROTECTED]> wrote: > > 1. about 10KB each. futon shows "16325 documents, total size 181.0 MB". > > 2. Ahh looks like after i do a fresh boot of couchdb and access one of > the > > views, I never see: > > /usr/local/lib/couchdb/bin/couchjs > /usr/local/share/couchdb/server/main.js > > When couchdb starts up, there is: > > /bin/sh -e /usr/local/bin/couchdb -c /usr/local/etc/couchdb/couch.ini -b > -r > > 5....... > > /bin/sh -e /usr/local/bin/couchdb -c /usr/local/etc/couchdb/couch.ini -b > -r > > 5..... > > /usr/lib/erlang/erts-5.5.2/bin/beam.smp -Bd -- ...... > > > > no couchjs (which I think is normal). When I access a different > database's > > view however, I see the couchjs process. Which seems to stick around even > > after the view data has been returned (normal?). However, the couchjs > > process never pops up if I access one of the views of the large database. > > 3. No havn't touched any of the documents after the timeout. Only > attemping > > to acces a view. > > 4. It exists. for the working databases, i see two "rck"s and then some > > binary content". For the large/non-working database, all I see is the > > "rck"s, I assume this means the views havn't been successfully compiled. > > > > So it looks like the issue is that it is failing when trying to spawn the > > couchjs process for the view. no? > > > > One thing to note that is different about this database is that for a > large > > amount of documents, it is using a URL (from a web crawl) for the ID, > > instead of the autogenerated one. > > > > Thanks for the help, > > Will > > > > On Thu, Sep 11, 2008 at 3:44 PM, Paul Davis <[EMAIL PROTECTED] > >wrote: > > > >> Things to check, > >> > >> 1. How big are your docs? > >> 2. Is there a javascript map process that's running even after the > >> view times out? > >> 3. Are you touching things even after a timeout? > >> 4. Check to make sure there's a design directory in the couchdb > >> directory. These files should be in ".db_name_design" > >> > >> For 3, if you get a time out, does it timeout a second time? Make sure > >> you don't touch anything though. Whenever your design doc changes the > >> entire view has to be rebuilt. > >> > >> Paul > >> > >> On Thu, Sep 11, 2008 at 3:31 PM, william kinney > >> <[EMAIL PROTECTED]> wrote: > >> > I simplified the map function to: > >> > > >> > function(doc) { > >> > emit(doc._id, doc); > >> > } > >> > > >> > and with count=3&update=false it is still timing out. I'm not sure > what > >> is > >> > going on. I forgot to mention, the server is a vmware image...but I > don't > >> > think that has anything do it with it (unless the disk io is being > >> mangled > >> > by vmware?). > >> > > >> > I have another database of 5000 records, and it's not having an issue > in > >> > accessing some of the views, even after some updates. Could it be > >> something > >> > in the data that is making the views fail? > >> > > >> > The only difference I can see between the two databases is that the > one > >> that > >> > is failing I created the views after inserting all 10k documents, the > 5k > >> it > >> > was before and somewhat incrementally updated as it grew. > >> > > >> > I suppose I'll try populating another database of 10k docs and see > what > >> > happens. > >> > > >> > I wish there was a way I could see how the view is progressing, other > >> than > >> > requesting and waiting. > >> > > >> > Thanks, > >> > Will > >> > > >> > On Thu, Sep 11, 2008 at 1:44 PM, Jeremy Wall <[EMAIL PROTECTED]> > wrote: > >> > > >> >> are you trying to return all of the documents at once? does it > improve > >> if > >> >> you restrict the results with a count=100 or similar? I can possibly > see > >> a > >> >> scenario where it might time out just trying to server several > thousand > >> >> documents to you at once. CouchDB doesn't exactly stream the > documents > >> to > >> >> you one at a time like a sql database might. > >> >> > >> >> On Thu, Sep 11, 2008 at 12:11 PM, william kinney > >> >> <[EMAIL PROTECTED]>wrote: > >> >> > >> >> > thanks for those! I was googling trying to find example reduce > >> functions, > >> >> > in > >> >> > vain. > >> >> > > >> >> > It seems my view (w/ reduce function removed) is still timing out. > >> >> > curl: (52) Empty reply from server > >> >> > > >> >> > real 85m15.699s > >> >> > > >> >> > I'm not sure what's going on. The map function isn't that > complicated. > >> >> Any > >> >> > ideas on how I could find out what's going on? > >> >> > > >> >> > Thanks, > >> >> > Will > >> >> > > >> >> > > >> >> > On Thu, Sep 11, 2008 at 1:08 AM, Chris Anderson <[EMAIL PROTECTED]> > >> wrote: > >> >> > > >> >> > > On Wed, Sep 10, 2008 at 7:25 PM, william kinney > >> >> > > <[EMAIL PROTECTED]> wrote: > >> >> > > > reduce function: > >> >> > > > function(keys, values) { > >> >> > > > return values; > >> >> > > > } > >> >> > > > > >> >> > > > >> >> > > The problem is with your reduce function (and the existing > >> >> > > documentation for reduce, which should make this clear, but > >> doesn't). > >> >> > > > >> >> > > Reduce should only be used to emit scalar values. In your case, > you > >> >> > > would be better not to define a reduce function at all, and just > >> query > >> >> > > the map with startkey and endkey ranges. For example reduce > >> functions, > >> >> > > see couch_tests.js's reduce test here: > >> >> > > > >> >> > > > >> >> > > > >> >> > > >> >> > >> > http://svn.apache.org/repos/asf/incubator/couchdb/trunk/share/www/script/couch_tests.js > >> >> > > > >> >> > > There are also some examples in various blog posts I've written > >> about > >> >> > > reduce: > >> >> > > > >> >> > > Google search for those posts: http://tinyurl.com/couchdb-reduce > >> >> > > > >> >> > > Hope this helps! > >> >> > > > >> >> > > Chris > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > -- > >> >> > > Chris Anderson > >> >> > > http://jchris.mfdz.com > >> >> > > > >> >> > > >> >> > >> > > >> > > >
