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
>>>>
