Thank you all for your answers,
I'll check all the solutions you suggested, In the meanwhile my couch works very good. It is very interesting that lucene is able to rise this kind of problems. Although the indexing in elasticsearch (es) is done only after 20 fields, the document itself contains ~ 100 fields and the entire document is retrieved through the river at insert/update time in couch (although this is configurable, but if one makes a search on a field which is not_analyzed, and not part of the index specification one could easily make simple searches on that field, as that field is not broken into tokens). Anyway the es index update is done almost instantly and works very good and the document is immediately exposed to search. The es developers refers to the couch feeding mechanism as an excellent one and indeed very few db engines have this kind of flexibility/ability. I have several couch databases (one server instance) running tru es river and only one of them has 100 fields and about 1.5 million documents. es and couch work very well together especially because there a re involved a timeout mechanism which should take care of responsiveness problems. As far as Erlang/OTP version is concerned, I have developed several client/server applications in Erlang using OTP platform, and they work well (after many error-and-trial cycles and a lot of prototyping) on Linux and UNIX, although a database server is a far more complicated engine than the ones I develop. Thank you for your suggestions, Bogdan On Fri, Dec 16, 2011 at 4:45 PM, CGS <[email protected]> wrote: > Hi, > > Could you try to insert a document manually in Futon without anything else > running on CouchDB? If yes, then it's not Erlang. > > There is another scenario which may provoke such an error: > 1. heart sends HB signal to CouchDB. > 2. CouchDB doesn't answer in time to heart because is busy with > elasticsearch + insert/update. > 3. heart kills CouchDB. > > Could you check memory/CPU consumption during your process? > > CGS > > PS: It wouldn't be the first time when Apache Lucene provokes > non-responsive CouchDB during the search. So, maybe someone should check > for the compatibility and usage limits. > > > > > > On 12/16/2011 12:50 PM, Peta Bogdan wrote: > >> The box looks like: >> >> OpenBSD 5.0 (GENERIC.MP) #63: Wed Aug 17 10:14:30 MDT 2011 >> [email protected]:/**usr/src/sys/arch/amd64/**compile/ >> GENERIC.MP >> real mem = 4292550656 (4093MB) >> avail mem = 4164161536 (3971MB) >> bios0: vendor Dell Inc. version "1.4.3" date 05/15/2009 >> bios0: Dell Inc. PowerEdge R200 >> cpu0: Intel(R) Xeon(R) CPU E3110 @ 3.00GHz, 3000.58 MHz >> cpu0: >> FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** >> CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** >> SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,**EST,TM2 >> ,SSSE3,CX16,xTPR,PDCM,SSE4.1,**XSAVE,NXE,LONG >> cpu0: 6MB 64b/line 16-way L2 cache >> cpu1: Intel(R) Xeon(R) CPU E3110 @ 3.00GHz, 3000.21 MHz >> cpu1: >> FPU,VME,DE,PSE,TSC,MSR,PAE,**MCE,CX8,APIC,SEP,MTRR,PGE,MCA,** >> CMOV,PAT,PSE36,CFLUSH,DS,ACPI,**MMX,FXSR,SSE,SSE2,SS,HTT,TM,** >> SBF,SSE3,MWAIT,DS-CPL,VMX,SMX,**EST,TM2 >> ,SSSE3,CX16,xTPR,PDCM,SSE4.1,**XSAVE,NXE,LONG >> cpu1: 6MB 64b/line 16-way L2 cache >> >> I had couchdb on R14B03 but didn't encountered such an issue although is >> not excluded to appear in this setup also. >> >> On Fri, Dec 16, 2011 at 1:39 PM, Dave Cottlehuber<[email protected]> >> wrote: >> >> On 16 December 2011 11:53, Peta Bogdan<[email protected]> wrote: >>> >>>> Thank you Dave, >>>> >>>> The fact that there are three parallel inserts on three different tables >>>> >>> on >>> >>>> the same server instance could trigger this this behaviour? >>>> >>> No. Either your couch is running on a very small box or there's some >>> other >>> issue relating to erlang itself. >>> >>> If you revert to R14B03 and rebuild couch etc, do you get similar issues? >>> >>> A+ >>> Dave >>> >>> >
