Should mention that r776685 translates to `svn up` :)

Paul

On Wed, May 20, 2009 at 9:10 AM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> Tim,
>
> Can you try r776685 and see if the problem persists?
>
> Paul Davis
>
> On Wed, May 20, 2009 at 8:52 AM, Tim Somers <somers.tim@gmail.com> wrote:
>> At first sight, I'm getting the same error once for each running process
>> using couchdb, so that makes 5 times. I'll repeat my test though, and check
>> if there's something different maybe in the first one.
>>
>> Tim
>>
>>
>> On Wed, May 20, 2009 at 12:47 PM, Damien Katz <damien@apache.org> wrote:
>>
>>> Are there more errors in the log? This error only makes sense to me if
>>> something else is restarting, because of a configuration change or because
>>> something else must have crashed beforehand. For example, running the test
>>> suite restarts components during testing which could cause a crash like
>>> this.
>>>
>>> -Damien
>>>
>>>
>>> On May 20, 2009, at 8:03 AM, Tim Somers wrote:
>>>
>>>  On Wed, May 20, 2009 at 11:57 AM, Paul Davis <paul.joseph.davis@gmail.com
>>>> >wrote:
>>>>
>>>>  On Wed, May 20, 2009 at 6:15 AM, Tim Somers <somers.tim@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm getting the exact same error:
>>>>>>
>>>>>> [error] [<0.7002.0>] {error_report,<0.22.0>,
>>>>>>  {<0.7002.0>,crash_report,
>>>>>>   [[{pid,<0.7002.0>},
>>>>>>     {registered_name,[]},
>>>>>>     {error_info,
>>>>>>         {exit,
>>>>>>             {timeout,
>>>>>>                 {gen_server,call,
>>>>>>                     [couch_config,
>>>>>>
>>>>>> {register,#Fun<couch_httpd.9.104562741>,<0.7002.0>}]}},
>>>>>>             [{gen_server,call,2},
>>>>>>              {couch_httpd,handle_request,4},
>>>>>>              {mochiweb_http,headers,5},
>>>>>>              {proc_lib,init_p_do_apply,3}]}},
>>>>>>
>>>>>> {initial_call,{mochiweb_socket_server,acceptor_loop,['Argument__1']}},
>>>>>>     {ancestors,
>>>>>>
>>>>>>  [couch_httpd,couch_secondary_services,couch_server_sup,<0.1.0>]},
>>>>>
>>>>>>     {messages,[]},
>>>>>>     {links,[<0.52.0>,#Port<0.4751>]},
>>>>>>     {dictionary,[]},
>>>>>>     {trap_exit,false},
>>>>>>     {status,running},
>>>>>>     {heap_size,2584},
>>>>>>     {stack_size,23},
>>>>>>     {reductions,1669}],
>>>>>>    []]}}
>>>>>> [error] [<0.52.0>] {error_report,<0.22.0>,
>>>>>>  {<0.52.0>,std_error,
>>>>>>   {mochiweb_socket_server,235,
>>>>>>       {child_error,
>>>>>>           {timeout,
>>>>>>               {gen_server,call,
>>>>>>                   [couch_config,
>>>>>>                    {register,#Fun<couch_httpd.9.104562741>,
>>>>>>                        <0.7002.0>}]}}}}}}
>>>>>>
>>>>>> =ERROR REPORT==== 20-May-2009::12:02:45 ===
>>>>>> {mochiweb_socket_server,235,
>>>>>>  {child_error,
>>>>>>      {timeout,
>>>>>>          {gen_server,call,
>>>>>>              [couch_config,
>>>>>>               {register,#Fun<couch_httpd.9.104562741>,<0.7002.0>}]}}}}
>>>>>>
>>>>>>
>>>>>>
>>>>>> although it seems to happen when the system is overloaded. In total, I
>>>>>>
>>>>> have
>>>>>
>>>>>> 5 processing constantly reading from and writing to the same couchdb,
>>>>>>
>>>>> with a
>>>>>
>>>>>> resulting load average of about 3 and physical memory at it's limit. I
>>>>>>
>>>>> get
>>>>>
>>>>>> the impression (though it's hard to reproduce) that this error come at
>>>>>>
>>>>> the
>>>>>
>>>>>> moment the system is swapping some ram out to disk, making couchdb run
>>>>>>
>>>>> into
>>>>>
>>>>>> some timeout while calculating a view.
>>>>>> Couchdb does stay online though, only crashing my app with an unusable
>>>>>> result.
>>>>>>
>>>>>>
>>>>> Can you check if couchdb actually stays alive or if it's getting
>>>>> respawned by heart? The easiest way to test this is to run couchdb
>>>>> with the command line without the init.d script.
>>>>>
>>>>> Erlang closes the entire VM when it's unable to acquire memory. Ie, if
>>>>> malloc returns NULL, then the whole VM closes. The general idea being
>>>>> that it'll just rely on heart to be restarted.
>>>>>
>>>>> Paul Davis
>>>>>
>>>>>  I'm using svn version 776257
>>>>>>
>>>>>> Tim
>>>>>>
>>>>>>
>>>>>
>>>> It stays alive, I always start it from command line. I use the svn version
>>>> on port 5985, and the version installed by debian package manager on port
>>>> 5984 for comparison.
>>>>
>>>> Tim
>>>>
>>>
>>>
>>
>