Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of tisdall@gmail.com designates
 209.85.217.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAJ_m3YDN4yfBtAiHbRURsCvQyUjOk8upY17fgXiJJCAvF5JZMA@mail.gmail.com>
References: 
 <CAGxYWpZh_pNz3gH-WW544M3h8+=nLFYQo8vipAQBOpaN2CJJGQ@mail.gmail.com>
	<CAJ_m3YAMRFjVrCROUNK05hTqXtCb7ieZ3ED5D9-G6RF+G+v7Eg@mail.gmail.com>
	<CAGxYWpae6_YdaTzgQwTxRGnDrdKxm8ZJwj5AQSdLyDN_BBWHag@mail.gmail.com>
	<CAJ_m3YDN4yfBtAiHbRURsCvQyUjOk8upY17fgXiJJCAvF5JZMA@mail.gmail.com>
Date: Thu, 16 Aug 2012 16:10:28 -0400
Message-ID: 
 <CAGxYWpb9dRD+aUUv7UOf9Nhxt7YgkUV7BG5JEEdOjvLK7ZFjZA@mail.gmail.com>
Subject: Re: couchdb returning empty response
From: Tim Tisdall <tisdall@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Things seemed to run despite those errors, but when the logging is in
"debug" I can see that the server does restart after outputting those
eaccess errors.  I see it in my application as getting a blank
response from the server.

On Thu, Aug 16, 2012 at 4:06 PM, Paul Davis <paul.joseph.davis@gmail.com> wrote:
> Never figured that issue out other than every single time its
> mentioned its a red herring. I think its just Erlang doing "WARNING:
> Everything is fine." type of logging.
>
> Odd that beam dies when gdb attaches to it. Not sure if that's
> important or not. I've definitely never seen such a thing.
>
> On Thu, Aug 16, 2012 at 2:19 PM, Tim Tisdall <tisdall@gmail.com> wrote:
>> Paul, did you ever solve the eaccess problem you had described here:
>> http://mail-archives.apache.org/mod_mbox/couchdb-user/201106.mbox/%3C4E0B304F.5080109@lymegreen.co.uk%3E
>>   I found that post from doing Google searches for my issue.
>>
>> On Tue, Aug 14, 2012 at 11:41 PM, Paul Davis
>> <paul.joseph.davis@gmail.com> wrote:
>>> On Tue, Aug 14, 2012 at 9:38 PM, Tim Tisdall <tisdall@gmail.com> wrote:
>>>> I'm still having problems with couchdb, but I'm trying out different
>>>> things to see if I can narrow down what the problem is...
>>>>
>>>> I stopped using fsockopen() in PHP and am using curl now to hopefully
>>>> be able to see more debugging info.
>>>>
>>>> I get an empty response when sending a POST to _bulk_docs.  From the
>>>> couch logs it seems like the server restarts in the middle of
>>>> processing the request.  Here's what I have in my logs:  (I have no
>>>> idea what the _replicator portion is about there, I'm currently not
>>>> using it)
>>>>
>>>>
>>>> [Wed, 15 Aug 2012 02:27:30 GMT] [debug] [<0.1255.0>] 'POST'
>>>> /app_stats_test/_bulk_docs {1,0} from "127.0.0.1"
>>>> Headers: [{'Accept',"*/*"},
>>>>           {'Content-Length',"2802300"},
>>>>           {'Content-Type',"application/json"},
>>>>           {'Host',"localhost:5984"}]
>>>> [Wed, 15 Aug 2012 02:27:30 GMT] [debug] [<0.1255.0>] OAuth Params: []
>>>> [Wed, 15 Aug 2012 02:27:45 GMT] [debug] [<0.115.0>] Include Doc:
>>>> <<"_design/_replicator">> {1,
>>>>                                                             <<91,250,44,153,
>>>>                                                               238,254,43,46,
>>>>                                                               180,150,45,181,
>>>>                                                               10,163,207,212>>}
>>>> [Wed, 15 Aug 2012 02:27:45 GMT] [info] [<0.32.0>] Apache CouchDB has
>>>> started on http://127.0.0.1:5984/
>>>>
>>>>
>>>> In my code logs I have the following by running curl in verbose mode:
>>>>
>>>> * About to connect() to localhost port 5984 (#0)
>>>> *   Trying 127.0.0.1... * connected
>>>> * Connected to localhost (127.0.0.1) port 5984 (#0)
>>>>> POST /app_stats_test/_bulk_docs HTTP/1.0
>>>> Host: localhost:5984
>>>> Accept: */*
>>>> Content-Type: application/json
>>>> Content-Length: 2802300
>>>>
>>>> * Empty reply from server
>>>> * Connection #0 to host localhost left intact
>>>> curl error: 52 : Empty reply from server
>>>>
>>>>
>>>>
>>>> I also tried using HTTP/1.1 and I get an empty response after
>>>> receiving only a "100 Continue", but the end result appears the same.
>>>>
>>>> -Tim
>>>
>>> If you have a request that triggers this, a good way to catch it is like such:
>>>
>>>     $ /usr/local/bin/couchdb # or however you start it
>>>     $ ps ax | grep beam.smp # Get the pid of couchdb
>>>     $ gdb
>>>        (gdb) attach $pid # Where $pid was just found with ps. Might
>>> throw up an access prompt
>>>        (gdb) continue
>>>        # At this point, run the command that makes couchdb reboot in a
>>>        # different console. If it happens you should see Gdb notice the
>>>        # error. Then the following:
>>>        (gdb) t a a bt
>>>
>>> And that should spew out a bunch of stack traces. If you can get that
>>> we should be able to fairly specifically narrow down the issue.