couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Mietz Egli (JIRA)" <j...@apache.org>
Subject [jira] Updated: (COUCHDB-991) Native query server show function does not respect os_process_timeout setting
Date Mon, 20 Dec 2010 21:09:01 GMT

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


Mime
View raw message