Uploaded image for project: 'Couchbase Java Client'
  1. Couchbase Java Client
  2. JCBC-20

CouchbaseClient instances consume all CPU resources

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: 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.

      1. ViewConnection.java
        10 kB
        Alan Wood
      1. resource_usage.png
        25 kB
      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        zortness 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
        zortness 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
        ingenthr 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
        ingenthr 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
        mikew 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
        mikew 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
        drakmir 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
        drakmir 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
        SteveC 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
        SteveC 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:
            mikew Mike Wiederhold
            Reporter:
            zortness Kurtis
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes