[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-369814422
We're now hard-rejecting attachments greater than `max_http_request_size`,
sadly.
@nickva I have an excellent reproducible case:
1. Build couchdb, master, latest.
1. Set up my `makeit.py` script from [this
comment](https://github.com/apache/couchdb/issues/745#issuecomment-351301113).
1. Run `dev/run -n 1 --with-admin-party-please`.
1. Run `curl -X PUT localhost:15984/foo`
1. Edit the URL in `makeit.py` to reflect `http://localhost:15984/foo`.
1. After entering the `virtualenv` for `makeit.py`, run: `python ./makeit.py
10 --size=7500`
1. Start a replication: `curl -X PUT localhost:15984/_replicator/bar -d
'{"source": "http://localhost:15984/foo;, "target":
"http://localhost:15984/bar;, "create_target": true}'`
1. Watch the sparks fly.
/cc @janl
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369814422
We're now hard-rejecting attachments greater than `max_http_request_size`,
sadly.
@nickva I have an excellent reproducible case:
1. Build couchdb, master, latest.
1. Set up my `makeit.py` script from [this
comment](https://github.com/apache/couchdb/issues/745#issuecomment-351301113).
1. Run `dev/run -n 1 --with-admin-party-please`.
1. Run `curl -X PUT localhost:15984/foo`
1. Edit the URL in `makeit.py` to reflect `http://localhost:15984/foo`.
1. After entering the `virtualenv` for `makeit.py`, run: `python ./makeit.py
50 --size=7500`
1. Start a replication: `curl -X PUT localhost:15984/_replicator/bar -d
'{"source": "http://localhost:15984/foo;, "target":
"http://localhost:15984/bar;, "create_target": true}'`
1. Watch the sparks fly.
/cc @janl
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369467559
Yes attachments. you can see revisions per doc are low. in the log.
Everything else is default. (Working around this by bumping the defaults is
just sweeping the error under the rug...)
Of course, we should be replicating the document. Why is it even getting a
413 in the first place? It's replicating a document from the same server to the
same server, no settings have changed, surely it should be able to PUT a
document it just did a GET of from itself. I believe this test (I didn't write
it) runs in a loop, so the data is being replicated over and over from one
database to the next on the same server.
Finally, even with a bumped `doc_write_failures` value, calling this a
`completed` replication is a VERY surprising result. Unless you think to check
`/_scheduler/docs` for the failed document count, or compare source/target
document counts, you'd never know there was a failure.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369467559
Yes attachments. you can see revisions per doc are low. in the log.
Everything else is default. (Working around this by bumping the defaults is
just sweeping the error under the rug...)
For the record, as I said on IRC, even with a bumped `doc_write_failures`
value, we should be replicating the document, not failing, since the DB has
been successfully replicated on the exact same cluster before. Even if it fails
once, it appears we didn't retry at all, or the retry failed; this is a VERY
surprising result and pretty unreasonable for the replication to end in a
`completed` not `failed` state.
Why is it even getting a 413 in the first place? It's replicating a document
from the same server to the same server, no settings have changed, surely it
should be able to PUT a document it just did a GET of from the same server.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369467559
Yes attachments. you can see revisions per doc are low. in the log.
Everything else is default. (Working around this by bumping the defaults is
just sweeping the error under the rug...)
For the record, as I said on IRC, even with a bumped `doc_write_failures`
value, we should be replicating the document, not failing, since the DB has
been successfully replicated on the exact same cluster before. Even if it fails
once, it appears we didn't retry at all, or the retry failed; this is a VERY
surprising result and pretty unreasonable for the replication to end in a
`completed` not `failed` state.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit a document. The replicator thinks it HAS successfully transferred the
document, and declares replication successful. A subsequent attempt to GET the
document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[notice] 2018-02-27T01:17:10.600494Z couchdb@127.0.0.1 <0.18679.277>
66a9b51dfd localhost:5984 127.0.0.1 undefined GET
/dba/foo?revs=true_revs=%5B%222-d32df74e77cfebcc08455cda37518117%22%5D=true
200 ok 2668
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened four times, so I'm
not sure I can provide an easy reproducer here, but we'll keep at it.
Couch was running at the info log level for this test, so I'm going bump it
up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit a document. The replicator thinks it HAS successfully transferred the
document, and declares replication successful. A subsequent attempt to GET the
document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[notice] 2018-02-27T01:17:10.600494Z couchdb@127.0.0.1 <0.18679.277>
66a9b51dfd localhost:5984 127.0.0.1 undefined GET
/db1/foo?revs=true_revs=%5B%222-d32df74e77cfebcc08455cda37518117%22%5D=true
200 ok 2668
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened four times, so I'm
not sure I can provide an easy reproducer here, but we'll keep at it.
Couch was running at the info log level for this test, so I'm going bump it
up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit a document. The replicator thinks it HAS successfully transferred the
document, and declares replication successful. A subsequent attempt to GET the
document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened four times, so I'm
not sure I can provide an easy reproducer here, but we'll keep at it.
Couch was running at the info log level for this test, so I'm going bump it
up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit a document. The replicator thinks it HAS successfully transferred the
document, and declares replication successful. A subsequent attempt to GET the
document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened once, so I'm not sure
I can provide an easy reproducer here.
Couch was running at the info log level for this test, so I'm going bump it
up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit an attachment. The replicator thinks it HAS successfully transferred
the document, and declares replication successful. A subsequent attempt to GET
the document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened once, so I'm not sure
I can provide an easy reproducer here.
Couch was running at the info log level for this test, so I'm going bump it
up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit an attachment. The replicator thinks it HAS successfully transferred
the document, and declares replication successful. A subsequent attempt to GET
the document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
Note that in extensive testing, this has only happened once, so I'm not sure
I can provide an easy reproducer here.
Couch was running at the default log level for this test, so I'm going bump
it up to debug level and try the test again, hoping for a duplicate.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-369447881
So in testing with a client, this no longer hangs/crashes/eats all the RAM,
but it does still cause an issue where a too-large request body fails to
transmit an attachment. The replicator thinks it HAS successfully transferred
the document, and declares replication successful. A subsequent attempt to GET
the document results in a 404.
Here is a censored excerpt from the logfile of the situation:
```
[notice] 2018-02-27T01:16:58.004513Z couchdb@127.0.0.1 <0.31509.279>
0f1a3bf01b localhost:5984 127.0.0.1 undefined GET
/_scheduler/docs/_replicator/862944988a0e42e8e7567da18c863571 200 ok 0
[notice] 2018-02-27T01:17:07.843508Z couchdb@127.0.0.1 <0.24829.275>
Starting replication 2def458d381dd99fa1f4e4887b5b9775+create_target
(http://localhost:5984/db1/ -> http://localhost:5984/db2/) from doc
_replicator:862944988a0e42e8e7567da18c863571 worker_procesess:4
worker_batch_size:500 session_id:bfafe761a21c1ea012228fc2df6790a9
[notice] 2018-02-27T01:17:07.843558Z couchdb@127.0.0.1 <0.24829.275>
Document `862944988a0e42e8e7567da18c863571` triggered replication
`2def458d381dd99fa1f4e4887b5b9775+create_target`
[error] 2018-02-27T01:17:10.869278Z couchdb@127.0.0.1 <0.23437.278>
Replicator: error writing document `foo` to `http://localhost:5984/db2/`:
{error,request_body_too_large}
[notice] 2018-02-27T01:17:27.107006Z couchdb@127.0.0.1 <0.24829.275>
Replication `2def458d381dd99fa1f4e4887b5b9775+create_target` completed
(triggered by `862944988a0e42e8e7567da18c863571`)
[notice] 2018-02-27T01:18:05.754340Z couchdb@127.0.0.1 <0.24230.274>
2a9c5d5507 localhost:5984 127.0.0.1 undefined GET /db2/foo 404 ok 1
```
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-366086057
Can anyone who is watching this bug tell me: If you stand up a CouchDB 2.0.0
instance separately, and use it to do the replication, do you still see the
problem?
A little explanation: the machine doing the actual replication doesn't have
to be the source *or* the target database. It can be a third party. So, the
idea is that your temporary CouchDB 2.0.0 instance would take the `/_replicate`
or `/_replicator` `PUT / POST` request, and your source and target
servers/databases would remain untouched.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-366066445
FYI, we have been notified by another client today that they are unable to
replicate databases off of Cloudant because of this bug. They have attachments,
but no attachment is larger than 2MB. It may be that multiple attachments are
being batched up and still running into the `max_http_request_size` being
small, but it's unclear.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv
python3-cxx-dev`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema urllib3 chardet
certifi idna`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
```
Repeat the above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful. This script creates
sample docs with a few fields and a 50MB attachment full of random bytes.
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target": true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5984/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv
python3-cxx-dev`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema urllib chardet
certifi idna`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
```
Repeat the above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful. This script creates
sample docs with a few fields and a 50MB attachment full of random bytes.
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target": true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5984/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv
python3-cxx-dev`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema urllib chardet
certifi idna`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
```
Repeat the above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful. This script creates
sample docs with a few fields and a 50MB attachment full of random bytes.
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target": true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv
python3-cxx-dev`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
```
Repeat the above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful. This script creates
sample docs with a few fields and a 50MB attachment full of random bytes.
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target: true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-359496713
@nickva @davisp The client has stated that the "similar issue" (with the
`couch_doc,'-doc_from_multi_part_stream/4-fun-1-',1,` function) only started
after an upgrade from `2.0.0rc3` to `2.1.1`.
Hopefully that narrows the git bisect a bit further?
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-359092280
One other thing - there was a previous attempt at changing some of this
behaviour that never landed that references some old JIRA tickets:
https://github.com/apache/couchdb/pull/138
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-359089695
FYI the intermittent network problems are not a prerequisite for this
problem to surface.
However, I think we are going in the right direction thinking this is
related to incorrect attachment length calculation and/or incomplete network
transfers.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
# repeat above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful.
```
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target: true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python ./makeit.py 10
```
Repeat the above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful.
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target: true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python makeit.py ./makeit.py 10
# repeat above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful.
```
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target: true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes. The command line returns:
```
{"error":"error","reason":"{worker_died,<0.26846.9>,{process_died,<0.27187.9>,kaboom}}"}
```
and the logfile has errors identical to that in the original post above, and
in #574.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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-351301113
Hey @nickva I spent time today on getting a repro for this, as it's
affecting more and more people. Bear with me on the setup, it's a little
involved.
Set up a VM with the following parameters (I used VMWare Workstation):
- 20GB HDD, 512 MB RAM (!), 1 CPU
- Debian 8.latest (or 9, I tested on 8), 64-bit
- CouchDB master - have it running on `localhost:5984` with `admin:password`
as the creds, `n=1`, and logging at `debug` level
- `sudo apt-get install stress python3 python3-virtualenv virtualenv`
- `mkdir 745 && cd 745 && virtualenv -p python3 venv && source
venv/bin/activate`
- `pip install RandomWords RandomIO requests docopt schema`
- `wget
https://gist.github.com/wohali/1cd19b78c0a417dbeb9f66b3229f7b58/raw/6539d48fa9e05b021f344b80fbf0d7c3e7fcd6e4/makeit.py`
Now you're ready to setup the test:
```
$ curl -X PUT http://admin:password@localhost:5984/foo
$ python makeit.py ./makeit.py 10
# repeat above a few times - get the DB to 1GB or larger. You can increase
10 but at some point you'll run out of RAM, so be careful.
```
Now to run the test:
* In one window: `tail -f | grep` your couch log for `mp_parser`.
* In another window, stress the machine's CPU and network: `stress --timeout
90m --cpu 1 --io 4`. (You can add disk access to this with `-d 8` if desired.
* In the window running the Python `virtualenv`, start the replication:
`curl http://admin:password@localhost:5984/_replicate -H "Content-Type:
application/json" --data '{"create_target: true, "source": "foo", "target":
"bar"}'`
If the above succeeds, `curl -X DELETE
http://admin:password@localhost:5985/bar` and try to replicate again.
This produces a failure for me within 10 minutes.
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:
us...@infra.apache.org
With regards,
Apache Git Services
[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:
us...@infra.apache.org
With regards,
Apache Git Services
