From user-return-26045-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Nov 14 11:25:34 2013 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D593710563 for ; Thu, 14 Nov 2013 11:25:34 +0000 (UTC) Received: (qmail 30878 invoked by uid 500); 14 Nov 2013 11:25:33 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 30590 invoked by uid 500); 14 Nov 2013 11:25:31 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 30582 invoked by uid 99); 14 Nov 2013 11:25:30 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 11:25:30 +0000 X-ASF-Spam-Status: No, hits=2.8 required=5.0 tests=HTML_MESSAGE,NORMAL_HTTP_TO_IP,RCVD_IN_DNSWL_LOW,SPF_PASS,URI_HEX,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of suraj.kumar@inmobi.com designates 209.85.223.170 as permitted sender) Received: from [209.85.223.170] (HELO mail-ie0-f170.google.com) (209.85.223.170) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Nov 2013 11:25:26 +0000 Received: by mail-ie0-f170.google.com with SMTP id to1so2473926ieb.1 for ; Thu, 14 Nov 2013 03:25:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=1XW7wUI1We0CXOZRb8j1BeW0vvjTCJlrxos7Li33I6Q=; b=CufGlUBLuWstlx0a74IrbvfTuslqG30AtFGqzmWoOKuW11RKEIXucvzgNyNBp2qPIb 4hUe2KaHMLoB3pakdRPztQXYe5SZIXwC6X4PoFzAq8pguSaY0g3amvHXw97PiaBkAIRY g5evmr1YeRVYL2ZjvXbKcnlSEC1qHsZHvDKXN9mMJsk/dOw2UDGFa3Z5CQZrOpdxKaGJ l+PaNS9NAbMjal5BB/K8TS5JKOrLEIYqs2eTsQu26n1ByBcEfQjVP73ToRjFz2UK1HN5 8WEBBVa8DAu/+R64NVfp6gjUTBr1c2zgkToKnyO2CF7A/ERDRqcUQWAui76Fmdq5xMvG p+qw== X-Gm-Message-State: ALoCoQlyOJTDElzeYoIRgNy7bXia8xRC++BzNHU+BHMkBYRx+0GwTav60YvRdRJGUcTdlYfeik4hDmbYYxmf7kKrk2RfMnbk0KZiWlG7KjKeg8Lz9e5Zgew= MIME-Version: 1.0 X-Received: by 10.50.127.197 with SMTP id ni5mr1029467igb.54.1384428305290; Thu, 14 Nov 2013 03:25:05 -0800 (PST) Received: by 10.64.224.244 with HTTP; Thu, 14 Nov 2013 03:25:05 -0800 (PST) Date: Thu, 14 Nov 2013 16:55:05 +0530 Message-ID: Subject: Weird lockup issue From: Suraj Kumar To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=089e013a286e5ac39604eb21559d X-Virus-Checked: Checked by ClamAV on apache.org --089e013a286e5ac39604eb21559d Content-Type: text/plain; charset=US-ASCII 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 ... 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. --089e013a286e5ac39604eb21559d--