incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suraj Kumar <suraj.ku...@inmobi.com>
Subject Weird lockup issue
Date Thu, 14 Nov 2013 11:25:05 GMT
Hi,

Our couchdb instance does not respond with full http response for some
specific documents from specific clients.

Ex:

[suraj@db1020 ~]$ hostname
db1020.mycompany.com
[suraj@db1020 ~]$ curl -v
http://ims08.mycompany.com:5984/ims/_design/ims_website/index.html
* About to connect() to ims08.mycompany.com port 5984 (#0)
*   Trying 192.168.136.197... connected
* Connected to ims08.mycompany.com (192.168.136.197) port 5984 (#0)
> GET /ims/_design/ims_website/index.html HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-unknown-linux-gnu) libcurl/7.19.7 NSS/
3.12.7.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: ims08.mycompany.com:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.4.0 (Erlang OTP/R14B04)
< ETag: "IEMyDzfk+wHbhhfypyUWfA=="
< Date: Thu, 14 Nov 2013 11:04:05 GMT
< Content-Type: text/html
< Content-Length: 19436
< Cache-Control: must-revalidate
< Accept-Ranges: none
<
^C (times out)

Whereas, when I connect to the same from another client, the call passes
smoothly:

[suraj@sunson:~] $ hostname
sunson.mycompany.com
[suraj@sunson:~] $ curl -v
http://ims08.mycompany.com:5984/ims/_design/ims_website/index.html | head
* About to connect() to ims08.mycompany.com port 5984 (#0)
*   Trying 192.168.136.197...
  % Total    % Received % Xferd  Average Speed   Time    Time     Time
 Current
                                 Dload  Upload   Total   Spent    Left
 Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--
  0* Connected to ims08.mycompany.com (192.168.136.197) port 5984 (#0)
> GET /ims/_design/ims_website/index.html HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ims08.mycompany.com:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.4.0 (Erlang OTP/R14B04)
< ETag: "IEMyDzfk+wHbhhfypyUWfA=="
< Date: Thu, 14 Nov 2013 11:05:17 GMT
< Content-Type: text/html
< Content-Length: 19436
< Cache-Control: must-revalidate
< Accept-Ranges: none
<
{ [data not shown]
 19 19436   19  3747    0     0   7056      0  0:00:02 --:--:--  0:00:02
 7083<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
...

As can be seen above, the first client failed whereas the second client
passed.

BUT, what is worth noting is:

[suraj@db1020 ~]$ curl -v http://ims08.mycompany.com:5984/ims/
* About to connect() to ims08.mycompany.com port 5984 (#0)
*   Trying 192.168.136.197... connected
* Connected to ims08.mycompany.com (192.168.136.197) port 5984 (#0)
> GET /ims/ HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-unknown-linux-gnu) libcurl/7.19.7 NSS/
3.12.7.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
> Host: ims08.mycompany.com:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: CouchDB/1.4.0 (Erlang OTP/R14B04)
< Date: Thu, 14 Nov 2013 11:15:58 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 241
< Cache-Control: must-revalidate
<
{"db_name":"ims","doc_count":954,"doc_del_count":18,"update_seq":979,"purge_seq":0,"compact_running":false,"disk_size":13209720,"data_size":7848911,"instance_start_time":"1384427320729766","disk_format_version":6,"committed_update_seq":979}

Some other requests pass from the same clients and some requests exhibit
above behaviour.

I've tried the following:
* replicating the DB to another host and hitting that new host - no help.
precisely same set of client machines run into same problems with same
documents.
* looking into logs, etc., in the server as well as on the client. I see
TCP connections being in ESTABLISHED state to 5984.

Please help!

  -Suraj

-- 
An Onion is the Onion skin and the Onion under the skin until the Onion
Skin without any Onion underneath.

-- 
_____________________________________________________________
The information contained in this communication is intended solely for the 
use of the individual or entity to whom it is addressed and others 
authorized to receive it. It may contain confidential or legally privileged 
information. If you are not the intended recipient you are hereby notified 
that any disclosure, copying, distribution or taking any action in reliance 
on the contents of this information is strictly prohibited and may be 
unlawful. If you have received this communication in error, please notify 
us immediately by responding to this email and then delete it from your 
system. The firm is neither liable for the proper and complete transmission 
of the information contained in this communication nor for any delay in its 
receipt.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message