Yes, reconfirmed my finding. I added ?LOG_INFO lines to the set_timeout clause in couch_native_server and it gets the current os_process_timeout value. That's a bit silly (given it's not an os process) but at least it's configurable. I stand by my original reply.
B. On 18 December 2013 18:31, Robert Newson <rnew...@apache.org> wrote: > couch_native_server has the set_timeout callback, though. I'll re-test > shortly. > > B. > > > On 18 December 2013 18:17, Alexander Shorin <kxe...@gmail.com> wrote: >> iirc native query server has hardcoded timeout 5000 and ignores >> os_process_timeout setting. >> -- >> ,,,^..^,,, >> >> >> On Wed, Dec 18, 2013 at 10:05 PM, Robert Newson <rnew...@apache.org> wrote: >>> I've confirmed that the native view server honors that timeout, can >>> you tell me what; >>> >>> curl localhost:5984/_config/couchdb/os_process_timeout >>> >>> returns? You might need to bounce couchdb in any case, as it applies >>> this timeout setting when it creates the process, and we keep a pool >>> of them around, so changes to timeout after that won't be picked up >>> until they're rebuild. restarting couchdb is the quickest way to >>> ensure that. >>> >>> B. >>> >>> >>> On 18 December 2013 16:20, david martin <david.mar...@lymegreen.co.uk> >>> wrote: >>>> Futon on Apache CouchDB 1.2 (according to Futon) >>>> {"couchdb":"Welcome","version":"1.2.0"} according to ? >>>> CouchDB 1.4.0 Ubuntu according to Package name >>>> >>>> I set os_process_timeout 50000000000000 (effective infinity). >>>> >>>> I ALWAYS get the VERY unhelpful message which merely prints the document >>>> contents. >>>> >>>> Error: timeout % yes I know this but cannot do anything about it >>>> >>>> {gen_server,call, % it's in a gen_server yes I know this! >>>> [<0.14190.8>, % this is its PID yes I know this! >>>> {prompt,[<<"map_doc">>, % it is a MAP function yes I know >>>> this! >>>> {[{<<"_id">>,<<"61c3f496b9e4c8dc29b95270d9000370">>}, % it is the document >>>> I >>>> am processing, Yes I know this! >>>> {<<"_rev">>,<<"9-e48194151642345e0e3a4a5edfee56e4">>}, >>>> ..... >>>> >>>> Yes it is a large and complex document (16K lines to make this happen on >>>> fast machine much less on Raspberry Pi). >>>> Yes it uses Erlang view function. >>>> Yes I DO want it to hog resources until it is finished. >>>> Yes I am the administrator. >>>> No I AM NOT INTERFERING WITH ANYTHING ELSE. >>>> No I cannot dictate how big or small the document is. >>>> Yes this is important to me. >>>> I have not pursued this as I was using rcouch, I could not find the source >>>> of the timeout message. >>>> I did not want to have to rebuild to fix this. >>>> I did not want to bother the Couchdb team as I was using a fork of CouchDB. >>>> Simlar issues have been raised and no answers forthcoming. >>>> Mentions of "hidden tweaks", "this is not good for you", "have you got big >>>> documents" etc. >>>> >>>> How do I get this NOT to timeout? >>>> >>>> On rcouch I would change a value and rebuild a release to fix this (if I >>>> could identify the source). >>>> If anybody can give a clue I will test their hypothesis and report back to >>>> the list. >>>> >>>> -- >>>> David Martin >>>>