Replies: 2 comments 7 replies
-
Try increasing |
Beta Was this translation helpful? Give feedback.
-
A couple of details to keep in mind here. The Conversely, setting a very large timeout factor will cause the system to wait approximately forever trying to open a slow shard file in a database with more than a few shards. That may not be desirable either ... This |
Beta Was this translation helpful? Give feedback.
-
No DB shards could be opened on single node under heavy parallel inserts. If I use q=1 then this error appears earlier, but if I increase q (f.e. q = 8) this error may not appear at all.
Logs:
[error] 2020-12-07T08:06:52.828447Z nonode@nohost <0.20294.2> 86e188ab8c req_err(1108989393) internal_server_error : No DB shards could be opened.
[<<"fabric_util:get_shard/4 L111">>,<<"fabric_util:get_shard/4 L128">>,<<"fabric:get_security/2 L183">>,<<"chttpd_auth_request:db_authorization_check/1 L110">>,<<"chttpd_auth_request:authorize_request/1 L19">>,<<"chttpd:handle_req_after_auth/2 L321">>,<<"chttpd:process_request/1 L306">>,<<"chttpd:handle_request_int/1 L244">>]
Steps to Reproduce
Pseudo-code on Java:
for (int i = 0; i < 60_000; i++) {
MyDoc d = new MyDoc();
d.setContent(doc);
db.async().saveOrUpdate(d).handle((r, t) -> { //ASYNC INSERT!
if (t != null) {
t.printStackTrace();
}
return null;
});
}
Expected Behaviour
Database should work slower and client should get request timeout.
Your Environment
CouchDB 3.1.1, Debian GNU/Linux 10 (buster)
Beta Was this translation helpful? Give feedback.
All reactions