Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Sun, 8 Apr 2012 15:36:19 +0000 (UTC)
From: "Randall Leeds (Updated) (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1850451281.958.1333899379107.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <773663395.30060.1332103003654.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Updated] (COUCHDB-1445) CouchDB deletes .view files if it
 can't open them, even if the error is "emfile".
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/COUCHDB-1445?page=3Dcom.atlass=
ian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Randall Leeds updated COUCHDB-1445:
-----------------------------------

    Affects Version/s:     (was: 1.2)
        Fix Version/s:     (was: 1.2.1)
                       1.2

This was fixed before the 1.2 release. It's open still because it needs a f=
orward-port, which I've committed myself to doing.
               =20
> CouchDB deletes .view files if it can't open them, even if the error is "=
emfile".
> -------------------------------------------------------------------------=
--------
>
>                 Key: COUCHDB-1445
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1445
>             Project: CouchDB
>          Issue Type: Bug
>          Components: JavaScript View Server
>    Affects Versions: 1.1.1, 1.3
>            Reporter: Jan Lehnardt
>            Assignee: Randall Leeds
>            Priority: Blocker
>             Fix For: 1.1.2, 1.2, 1.3
>
>
> Via Stefan K=C3=B6gl on dev@:
> Another thing I noticed during my tests of CouchDB 1.2.x. I redirected
> live traffic to the instance and after a rather short time, requests
> were failing with the following information in the logs:
> [Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
> {error_report,<0.31.0>,
>                                    {<0.27554.2>,std_error,
>                                     [{application,mochiweb},
>                                      "Accept failed error",
>                                      "{error,emfile}"]}}
> [Sun, 18 Mar 2012 16:39:24 GMT] [error] [<0.27554.2>]
> {error_report,<0.31.0>,
>                          {<0.27554.2>,crash_report,
>                           [[{initial_call,
>                                 {mochiweb_acceptor,init,
>                                     ['Argument__1','Argument__2',
>                                      'Argument__3']}},
>                             {pid,<0.27554.2>},
>                             {registered_name,[]},
>                             {error_info,
>                                 {exit,
>                                     {error,accept_failed},
>                                     [{mochiweb_acceptor,init,3},
>                                      {proc_lib,init_p_do_apply,3}]}},
>                             {ancestors,
>                                 [couch_httpd,couch_secondary_services,
>                                  couch_server_sup,<0.32.0>]},
>                             {messages,[]},
>                             {links,[<0.129.0>]},
>                             {dictionary,[]},
>                             {trap_exit,false},
>                             {status,running},
>                             {heap_size,233},
>                             {stack_size,24},
>                             {reductions,244}],
>                            []]}}
> I think "emfile" means that CouchDB (or mochiweb?) couldn't open any
> more files / connections. I've set the (hard and soft) nofile limit for
> user couchdb to 4096, but didn't raise the ERL_MAX_PORTS accordingly.
> Anyway, as soon as the error occured, CouchDB started writing most of my
> view files from scratch, rendering the instance unusable.
> I'd expect CouchDB to fail more gracefully when the maximum number of
> open files is reached. Is this a bug or expected behaviour?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
For more information on JIRA, see: http://www.atlassian.com/software/jira