[MB-6339] Stop rebalance can take a long time to take effect if we have compaction and indexing are in progress Created: 20/Aug/12  Updated: 09/Jan/13  Resolved: 25/Oct/12

Status: Closed
Project: Couchbase Server
Component/s: documentation, UI
Affects Version/s: 2.0-beta
Fix Version/s: feature-backlog
Security Level: Public

Type: Bug Priority: Minor
Reporter: Karan Kumar (Inactive) Assignee: Aleksey Kondratenko
Resolution: Duplicate Votes: 0
Labels: 2.0-beta-release-notes, 2.0-release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 2.0.0-1613-rel

Attachments: PNG File Screen Shot 2012-08-20 at 7.07.04 PM.png     Zip Archive stop_rebalance_log.zip    

 Description   
2 buckets (~10 M items)
10 index building in progress
3 compaction on views in progress

The CPU usage here was about 80% on the orchestrator.

It took about 10 mins for stop rebalance to take effect, from user perpective, it seems as though stop rebalance did not work.
We could can log in UI, saying that stop rebalance is in progress, since, I believe stop rebalance is asyn call.

Attaching the cbcollect_logs from the orchestrator.





 Comments   
Comment by Aleksey Kondratenko [ 20/Aug/12 ]
There's even larger problem I'm aware of. Sometimes it needs really long time to stop if. For example when some node is totally down.
Comment by MC Brown (Inactive) [ 17/Oct/12 ]
I've added a note to the release notes as a known issue for this behaviour.
Comment by MC Brown (Inactive) [ 17/Oct/12 ]
Has the UI component been changed? If not, it should be reassigned for a fix.
Comment by Steve Yen [ 25/Oct/12 ]
alk makes more sense than peter for assignment
Comment by Aleksey Kondratenko [ 25/Oct/12 ]
Fixed already.
Generated at Tue Jul 29 02:04:30 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.