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
Matt Ingenthron
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Deepkaran Salooja [ deepkaran.salooja ] | Sergey Avseyev [ avsej ] |
Sergey Avseyev
made changes -
Sergey Avseyev
made changes -
| Comment | [ issue still there ] |
Steve Yen
made changes -
| Assignee | Sergey Avseyev [ avsej ] | Aleksey Kondratenko [ alkondratenko ] |
| Fix Version/s | .next [ 10342 ] | |
| Fix Version/s | 2.0 [ 10114 ] | |
| Affects Version/s | 2.0-beta-2 [ 10385 ] |
Steve Yen
made changes -
| Labels | 2.0-release-notes |
Aleksey Kondratenko
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Fix Version/s | .next [ 10342 ] | |
| Resolution | Duplicate [ 3 ] |
Sergey Avseyev
made changes -
Matt Ingenthron
made changes -
| Assignee | Aleksey Kondratenko [ alkondratenko ] | Matt Ingenthron [ ingenthr ] |
Matt Ingenthron
made changes -
| Planned End | (re-schedule end date based on new assignee) |
Matt Ingenthron
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Aleksey Kondratenko
made changes -
| Resolution | Duplicate [ 3 ] | |
| Status | Closed [ 6 ] | Reopened [ 4 ] |
| Assignee | Matt Ingenthron [ ingenthr ] | Aleksey Kondratenko [ alkondratenko ] |
Aleksey Kondratenko
made changes -
| Planned End | (re-schedule end date based on new assignee) |
Aleksey Kondratenko
made changes -
| Summary | there are reports that even after invoking FLUSH nodes return TMPFAIL ( spec says when flush returns node should be ready ) | if flush times out final stage (janitor creating vbuckets back) it returns success causing clients to see TMPFAIL after flush succeeds (WAS: there are reports that even after invoking FLUSH nodes return TMPFAIL...) |
| Affects Version/s | 2.0.1 [ 10399 ] | |
| Affects Version/s | 2.0.2 [ 10418 ] | |
| Priority | Major [ 3 ] | Minor [ 4 ] |
| 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. |
"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. |
| Component/s | couchbase-bucket [ 10173 ] |
Matt Ingenthron
made changes -
| 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. |
"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. |
Matt Ingenthron
made changes -
| Priority | Minor [ 4 ] | Major [ 3 ] |