couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Mohr <r...@kumu.io>
Subject Fwd: Requests silently failing
Date Wed, 30 Oct 2013 22:58:25 GMT
Hey Alex,

Correct on the request chain.  And both excon and couchdb are using tcp
nodelay if that makes any difference.

I had looked into tcpdump but was in over my head.  I could see traffic
passing through 6984 but couldn't tell if the requests and responses were
complete or not. Doesn't help that all the traffic is encrypted either.

Here's the command I was using: sudo tcpdump -vv -n 'tcp port 6984'

If the response was being sent, any idea why I wouldn't see the [info]
level confirmation in the logs?

---------- Forwarded message ----------
From: Alexander Shorin <kxepal@gmail.com>
Date: Wed, Oct 30, 2013 at 10:48 AM
Subject: Re: Requests silently failing
To: "user@couchdb.apache.org" <user@couchdb.apache.org>


Hi Ryan,

Have you tried to see with tcpdump/wireshark if CouchDB actually sends
the response? Just to be sure, that this is not third-party tools
problem.

P.S. am I understood right that the request chain is user -> rails ->
excon -> couchdb ?
--
,,,^..^,,,


On Thu, Oct 31, 2013 at 12:39 AM, Ryan Mohr <ryan@kumu.io> wrote:
> Lately I've been running into an annoying bug where requests are silently
> being dropped.  They're logged at the debug level and then nothing
happens.
>  No error and no info level confirmation that the request went through.
>
> This only seems to happen with PUT/POST requests and only once the
> connection (persistent ssl, nodelay) has been idle for a few minutes.
>
> I'm using the excon library to proxy the requests through a rails app.
>  Originally I thought it was an excon issue but now I'm not so sure.  A
> complete background can be found in the original github issue:
>
> https://github.com/geemus/excon/issues/268#issuecomment-27355940
>
> Anyone experienced this before?
>
> CouchDB Version: 1.4.0
> Excon Version: 0.27.6
>
> (Sorry if this is a duplicate post. Didn't look like the original one went
> through.)

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