Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Cannot Reproduce
    • Affects Version/s: 1.8.1, 2.0
    • Fix Version/s: bug-backlog
    • Component/s: moxi
    • Security Level: Public
    • Labels:
      None
    • Environment:
      Windows Server (Service Pack 2)
    • Triage:
      Untriaged

      Description

      Moxi.exe runs into the assertion described below during the Couchbase Server startup. This causes memcached to restart a couple of times (2 - 3) before completing its warmup.

      Assertion fail message from Couchbase Server log:

      Port server memcached on node 'ns_1@10.3.121.142' exited with status 255. Restarting. Messages: Assertion failed!

      Program: c:\opt\couchbase\bin\moxi.exe
      File: cproxy.c, Line 157

      Expression: port > 0 || settings.socketpath != NULL

      This application has requested the Runtime to terminate it in an unusual way.
      Please contact the application's support team for more information.

      Memcached.exe command line:
      c:\opt\couchbase\bin\memcached.exe -X c:\opt\couchbase\lib\memcached\stdin_term_handler.so -l 0.0.0.0:11210,0.0.0.0:11209:1000 -E c:/opt/couchbase/lib/memcached/bucket_engine.so -B binary -r -c 10000 -e admin=_admin;default_bucket_name=default;auto_create=fal

      No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

        Hide
        jin Jin Lim (Inactive) added a comment -

        This appears to be a Windows platform specific issue.

        Show
        jin Jin Lim (Inactive) added a comment - This appears to be a Windows platform specific issue.
        Hide
        scepak Slawek added a comment -

        This is happening to me now every day on two servers Win server 2003 & 2008 with Couchbase 1.8.0 & 1.8.1

        I don't see any other errors, so I'm not sure what's causing it. After moxi restarts caching is not working until I restart applications in IIS.

        ############################################################
        Port server moxi on node 'ns_1@192.168.243.12' exited with status 3. Restarting. Messages: 2012-09-10 17:13:21: (cproxy_config.c.317) env: MOXI_SASL_PLAIN_USR (7)
        2012-09-10 17:13:21: (cproxy_config.c.326) env: MOXI_SASL_PLAIN_PWD (9)
        Assertion failed!

        Program: d:\Program Files\Couchbase\Server\bin\moxi.exe
        File: cproxy_protocol_b2b.c, Line 56

        Expression: uc->noreply == false

        This application has requested the Runtime to terminate it in an unusual way.
        Please contact the application's support team for more information.
        ############################################################

        Show
        scepak Slawek added a comment - This is happening to me now every day on two servers Win server 2003 & 2008 with Couchbase 1.8.0 & 1.8.1 I don't see any other errors, so I'm not sure what's causing it. After moxi restarts caching is not working until I restart applications in IIS. ############################################################ Port server moxi on node 'ns_1@192.168.243.12' exited with status 3. Restarting. Messages: 2012-09-10 17:13:21: (cproxy_config.c.317) env: MOXI_SASL_PLAIN_USR (7) 2012-09-10 17:13:21: (cproxy_config.c.326) env: MOXI_SASL_PLAIN_PWD (9) Assertion failed! Program: d:\Program Files\Couchbase\Server\bin\moxi.exe File: cproxy_protocol_b2b.c, Line 56 Expression: uc->noreply == false This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ############################################################
        Hide
        steve Steve Yen added a comment -

        scrubbing ancient moxi bugs...

        One way this might happen (uc->noreply == true) is if you're using a quiet binary command and somehow the logic in moxi got bungled. One potential candidate...

        memcached.c
        void process_bin_noreply(conn *c) {
        assert(c);
        c->noreply = true;
        switch (c->binary_header.request.opcode)

        { case PROTOCOL_BINARY_CMD_SETQ: c->cmd = PROTOCOL_BINARY_CMD_SET; break; ... more cases here ... default: c->noreply = false; }

        }

        No one else has reported any issues around this, though, so perhaps this (admitedlly, probably too optimistically) was taken care of via other fixes over the years, especially with the latest 3.0 rework.

        Show
        steve Steve Yen added a comment - scrubbing ancient moxi bugs... One way this might happen (uc->noreply == true) is if you're using a quiet binary command and somehow the logic in moxi got bungled. One potential candidate... memcached.c void process_bin_noreply(conn *c) { assert(c); c->noreply = true; switch (c->binary_header.request.opcode) { case PROTOCOL_BINARY_CMD_SETQ: c->cmd = PROTOCOL_BINARY_CMD_SET; break; ... more cases here ... default: c->noreply = false; } } No one else has reported any issues around this, though, so perhaps this (admitedlly, probably too optimistically) was taken care of via other fixes over the years, especially with the latest 3.0 rework.
        Hide
        raju Raju Suravarjjala added a comment -

        Bulk closing all invalid bugs that are duplicate, user error, invalid. Please feel free to reopen them if you feel otherwise

        Show
        raju Raju Suravarjjala added a comment - Bulk closing all invalid bugs that are duplicate, user error, invalid. Please feel free to reopen them if you feel otherwise

          People

          • Assignee:
            steve Steve Yen
            Reporter:
            jin Jin Lim (Inactive)
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes