Details
-
Type:
Bug
-
Status:
Reopened
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0-beta-2, 2.0.1, 2.0.2
-
Fix Version/s: None
-
Component/s: ns_server
-
Security Level: Public
-
Labels:
Description
"reported by SDK team"
After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.
update:
I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.
further update:
I disagree on the "always be able to handle TMPFAIL", especially in the case of running tests at the SDK side. At the moment, we ask our users to handle tmpfail directly. That's intentional and seems to make sense as a pressure relief valve for steady state, but between these flushes and especially from unit tests, it'd be best if the cluster could just block either the operation request or the flush response until complete.
Raising this to major owing to end-user reports of trouble here.
After a flush (through REST) for a time we still get tmpfail returned by server nodes. This is not expected, and would be kind of annoying from an application and/or cause problems with automated tests.
update:
I've updated subject. Indeed this is possible. But IMHO given that clients should always be prepared to handle TMPFAIL out of everything I've lowered down to minor.
further update:
I disagree on the "always be able to handle TMPFAIL", especially in the case of running tests at the SDK side. At the moment, we ask our users to handle tmpfail directly. That's intentional and seems to make sense as a pressure relief valve for steady state, but between these flushes and especially from unit tests, it'd be best if the cluster could just block either the operation request or the flush response until complete.
Raising this to major owing to end-user reports of trouble here.
Issue Links
- duplicates
-
MB-6232
ep-engine needs 1.5 minutes to create 1k vbuckets. Seems too slow (but gets fast with barrier=0)
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Gerrit Reviews