Couchbase Java Client

CouchbaseClient instances consume all CPU resources

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: None
  • Fix Version/s: 1.1dp2
  • Component/s: None
  • Security Level: Public
  • Labels:
    None
  • Environment:
    Win7, centOS 5.4, tomcat 6.x, java 1.6.x

Description

When creating one or more CouchbaseClient instances, each one appears to consume 100% of the available CPU resources per core, at least on machines I've tested.
Test case (eclipse project and ant build) included.
Also included a snapshot of my system graph on my dev machine while running the included test.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Kurtis added a comment -
Also relevant are, this issue at google code:
http://code.google.com/p/spymemcached/issues/detail?id=218

And this thread in the Couchbase forums:
http://www.couchbase.org/forums/thread/using-couchbaseclient-connect
Show
Kurtis added a comment - Also relevant are, this issue at google code: http://code.google.com/p/spymemcached/issues/detail?id=218 And this thread in the Couchbase forums: http://www.couchbase.org/forums/thread/using-couchbaseclient-connect
Hide
Permalink
Matt Ingenthron added a comment -
I've reproduced this issue.

After investigating it a bit, I've found that simplifying the test to use either MemcachedClient or MembaseClient doesn't demonstrate the same issue. Under both of those, CPU usage is modest.

Further, more profiling seemed to show time on MacOS off in kqueue poll from the CouchbaseNode's run() method.

I suspect there's a thread safety issue here causing badness.

Asking Mike to review for any possible thread safety issues when there are multiple CouchbaseClients running.
Show
Matt Ingenthron added a comment - I've reproduced this issue. After investigating it a bit, I've found that simplifying the test to use either MemcachedClient or MembaseClient doesn't demonstrate the same issue. Under both of those, CPU usage is modest. Further, more profiling seemed to show time on MacOS off in kqueue poll from the CouchbaseNode's run() method. I suspect there's a thread safety issue here causing badness. Asking Mike to review for any possible thread safety issues when there are multiple CouchbaseClients running.
Hide
Permalink
Mike Wiederhold added a comment -
Were currently moving a few things around in the client. No user facing API changes, but still moving this around. I'll make sure to get this fixed as soon as possible though.
Show
Mike Wiederhold added a comment - Were currently moving a few things around in the client. No user facing API changes, but still moving this around. I'll make sure to get this fixed as soon as possible though.
Hide
Permalink
Alan Wood added a comment -
I've put a possible fix as an attachment to this issue. It works for us, and doesn't block shutdown, other nodes, etc.

The file was also submitted here (as an alternative to the ViewNode patch placed there earlier):
http://www.couchbase.com/issues/browse/JCBC-26
Show
Alan Wood added a comment - I've put a possible fix as an attachment to this issue. It works for us, and doesn't block shutdown, other nodes, etc. The file was also submitted here (as an alternative to the ViewNode patch placed there earlier): http://www.couchbase.com/issues/browse/JCBC-26
Hide
Permalink
Steven Cooke added a comment -
Is this still open? ViewConnection and CouchbaseConnection are both threads with tight run loops. The quick fix is to sleep(50) or so. Not sure what the real solution should be, but it seems any threaded connection to the server to get server state can be handled by a singleton.

e.g.

public void run() {
  while(true) {}
}

vs

public void run() {
  while (true) {
    sleep(50); // utility function to hide try/catch
  }
}

First will hose the CPU, second will not
     
Show
Steven Cooke added a comment - Is this still open? ViewConnection and CouchbaseConnection are both threads with tight run loops. The quick fix is to sleep(50) or so. Not sure what the real solution should be, but it seems any threaded connection to the server to get server state can be handled by a singleton. e.g. public void run() {   while(true) {} } vs public void run() {   while (true) {     sleep(50); // utility function to hide try/catch   } } First will hose the CPU, second will not      

People

  • Assignee:
    Mike Wiederhold
    Reporter:
    Kurtis
Vote (0)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved: