[jira] Updated: (COUCHDB-991) Native query server show function does not respect os_process_timeout setting

["Paul Mietz Egli (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COUCHDB-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Mietz Egli updated COUCHDB-991:
------------------------------------

    Description: 
I have a design document containing show functions written in Erlang for performance reasons, and I found that some calls to these shows were timing out after about eight seconds (according to curl).  I increased os_process_timeout to 300000 but still saw the show timing out after seven or eight seconds.  Log shows:

{exit, {timeout, {gen_server,call, [<0.135.0>,{prompt,[my data]}]}}}

I asked about this problem in IRC, and kocolosk said that the problem is that couch_native_process only checks the timeout for a couple of commands, like list_row.  The gen_server:call/2 function is timing out because ddoc(...<<"show">>) is taking more than five seconds to process.  Changing line 63 to the following prevents the timeout:

gen_server:call(Pid, {prompt, Data}, infinity)

Ideally, though, each run/2 call in couch_native_process would respect the configured timeout value.  Workaround for now is to wrap the ddoc(..<<"shows">>..)  call in a timer using State#evstate.timeout as a duration (thanks for the solution, kocolosk!).

  was:
I have a design document containing show functions written in Erlang for performance reasons, and I found that some calls to these shows were timing out after about eight seconds (according to curl).  I increased os_process_timeout to 300000 but still saw the show timing out after seven or eight seconds.  Log shows:

{code:none}
{exit, {timeout, {gen_server,call, [<0.135.0>,{prompt,[my data]}]}}}
{code}

I asked about this problem in IRC, and kocolosk said that the problem is that couch_native_process only checks the timeout for a couple of commands, like list_row.  The gen_server:call/2 function is timing out because ddoc(...<<"show">>) is taking more than five seconds to process.  Changing line 63 to the following prevents the timeout:

{code:none}
gen_server:call(Pid, {prompt, Data}, infinity)
{code}

Ideally, though, each run/2 call in couch_native_process would respect the configured timeout value.  Workaround for now is to wrap the ddoc(..<<"shows">>..)  call in a timer using State#evstate.timeout as a duration (thanks for the solution, kocolosk!).


> Native query server show function does not respect os_process_timeout setting
> -----------------------------------------------------------------------------
>
>                 Key: COUCHDB-991
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-991
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 1.0.1
>         Environment: Mac OSX 10.6; CouchDB/1.0.1 (Erlang OTP/R13B)
>            Reporter: Paul Mietz Egli
>
> I have a design document containing show functions written in Erlang for performance reasons, and I found that some calls to these shows were timing out after about eight seconds (according to curl).  I increased os_process_timeout to 300000 but still saw the show timing out after seven or eight seconds.  Log shows:
> {exit, {timeout, {gen_server,call, [<0.135.0>,{prompt,[my data]}]}}}
> I asked about this problem in IRC, and kocolosk said that the problem is that couch_native_process only checks the timeout for a couple of commands, like list_row.  The gen_server:call/2 function is timing out because ddoc(...<<"show">>) is taking more than five seconds to process.  Changing line 63 to the following prevents the timeout:
> gen_server:call(Pid, {prompt, Data}, infinity)
> Ideally, though, each run/2 call in couch_native_process would respect the configured timeout value.  Workaround for now is to wrap the ddoc(..<<"shows">>..)  call in a timer using State#evstate.timeout as a duration (thanks for the solution, kocolosk!).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.