couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Tisdall <tisd...@gmail.com>
Subject Re: couchdb returning empty response
Date Fri, 17 Aug 2012 17:30:49 GMT
Okay, so it always states that _replicator line any time I manually
restart the server.  I think it's just a standard logging message when
the level is set to "debug".

On Fri, Aug 17, 2012 at 1:13 PM, Tim Tisdall <tisdall@gmail.com> wrote:
> No.  All my ids (except for design documents) are strings containing
> integers.  Also, none of my design documents are called anything like
> "_replicator".  The only thing with that name is in the _replicator
> database which I'm not doing anything with.
>
> Why does it say "Include Doc"?  And what's that series of numbers
> afterwards?  That log message seems to consistently occur just before
> the log message about the server starting.  Is that just a normal
> message you get when the server restarts and you have logging set to
> "debug"?
>
>
> On Fri, Aug 17, 2012 at 1:03 PM, Robert Newson <rnewson@apache.org> wrote:
>>
>> Does app_stats_test contain a document called _design/_replicator or is a document
with that id in the body of your bulk post?
>>
>> B.
>>
>> On 17 Aug 2012, at 17:52, Tim Tisdall wrote:
>>
>>> I do have UTF8 characters in the JSON, but isn't that acceptable?  I
>>> have no problem retrieving UTF8 encoded content from the server and I
>>> have a bunch of it saved in there already too.
>>>
>>> On Fri, Aug 17, 2012 at 10:35 AM, CGS <cgsmcmlxxv@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> Do you have somehow special characters (non-latin1 ones) in your JSON? That
>>>> error looks strangely close to trying to transform a list of unicode
>>>> characters into a binary. I might be wrong though.
>>>>
>>>> CGS
>>>>
>>>>
>>>>
>>>> On Fri, Aug 17, 2012 at 4:09 PM, Tim Tisdall <tisdall@gmail.com> wrote:
>>>>
>>>>> I thought I added that to the init script before when you mentioned
>>>>> it, but I checked and it was gone.  I added a "cd ~couchdb" in there
>>>>> and now I no longer get eaccess errors, but the process still crashes
>>>>> with very little information:
>>>>>
>>>>> [Fri, 17 Aug 2012 14:01:44 GMT] [debug] [<0.1372.0>] 'POST'
>>>>> /app_stats_test/_bulk_docs {1,0} from "127.0.0.1"
>>>>> Headers: [{'Accept',"*/*"},
>>>>>          {'Content-Length',"3902444"},
>>>>>          {'Content-Type',"application/json"},
>>>>>          {'Host',"localhost:5984"}]
>>>>> [Fri, 17 Aug 2012 14:01:44 GMT] [debug] [<0.1372.0>] OAuth Params:
[]
>>>>> [Fri, 17 Aug 2012 14:02:16 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>>}
>>>>> [Fri, 17 Aug 2012 14:02:17 GMT] [info] [<0.32.0>] Apache CouchDB
has
>>>>> started on http://127.0.0.1:5984/
>>>>>
>>>>>
>>>>> Someone mentioned seeing the JSON that I'm submitting...  Wouldn't
>>>>> mal-formed JSON throw an error?
>>>>>
>>>>> -Tim
>>>>>
>>>>>
>>>>> On Fri, Aug 17, 2012 at 4:33 AM, Robert Newson <rnewson@apache.org>
wrote:
>>>>>>
>>>>>> I've seen couchdb start despite the eacces errors before and tracked
it
>>>>> down to the current working directory setting. It seems that the cwd
is
>>>>> searched first, and then erlang looks elsewhere. So, if our startup script
>>>>> doesn't change it to somewhere that the couchdb user can read, you get
>>>>> spurious eacces errors.
>>>>>>
>>>>>> Don't ask me how I know this.
>>>>>>
>>>>>> B.
>>>>>>
>>>>>> On 16 Aug 2012, at 20:19, Tim Tisdall 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.
>>>>>>
>>>>>
>>

Mime
View raw message