You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by gi...@git.apache.org on 2017/10/05 21:49:17 UTC
[GitHub] wohali commented on issue #745: Replication with attachments never completes, {mp_parser_died,noproc} error
wohali commented on issue #745: Replication with attachments never completes, {mp_parser_died,noproc} error
URL: https://github.com/apache/couchdb/issues/745#issuecomment-334601791
Seeing this now in multiple production environments. In one case, it is potentially completely freezing a node participating in continuous replication with large attachments. In the other, it's a one-time replication that must be restarted many times before it runs to completion.
Discussion on IRC today with @nickva follows.
```
17:17 < vatamane> #574 was mostly about how 413 (request too big) are handled
17:17 <+Wohali> right, and in both cases these are large attachments
17:18 < vatamane> do you think they trigger the 413 that is, are they bigger
than the maximum size request setting?
17:19 <+Wohali> very likely
17:20 < vatamane> k, yeah this is tricky one
17:20 < vatamane> I was trying to think what the patch would be for ibrowse and
got thoroughly confused by its parsing state machine
17:22 < vatamane> mochiweb (the server) might also have to behave nicely to
ensure it actually sends out the 413 response before closing
the streams
17:23 <+Wohali> hm
17:23 <+Wohali> https://github.com/cmullaparthi/ibrowse/issues/105
17:24 <+Wohali> and of course https://github.com/cmullaparthi/ibrowse/issues/146
17:24 <+Wohali> which might prevent us from moving to 4.3
17:24 <+Wohali> or i guess 4.4 now
17:28 < vatamane> the fix here might also need the setting of erlang's socket
options
17:29 < vatamane> namely {exit_on_close, false}
17:30 < vatamane> i meant to say ibrowse lets us set socket options, i remember
trying but it wasn't enough
17:32 < vatamane> also i remember testing the server side with this script
https://gist.github.com/nickva/84bbe3a51b9ceda8bca8256148be1a18
17:32 < vatamane> it opens a plain socket for upload then even on send failure
tries to receive data
17:32 <+Wohali> right so we agree the issue is probably ibrowse?
17:33 < vatamane> 80% or so sure
17:36 <+Wohali> we could run that eunit test in a loop, I mean
17:37 < vatamane> yap could do that
17:37 < vatamane> I was doing it that way
17:37 < vatamane> with debugging and logging enabled
```
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services