Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-8149

Status Message Garbage against a Windows Cluster

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 2.0, 2.0.1
    • Fix Version/s: 2.2.0
    • Component/s: clients
    • Security Level: Public
    • Labels:
    • Operating System:
      Windows 32-bit

      Description

      Something that was reported earlier somewhere, but I could never track it down until now.

      I'm currently at the DevDay vienna and one person used the Java SDK against a Windows Couchbase Server 2.0 install (locally). So everything works well, but when he wants to print out the status message on async operations the string that comes back is total garbage. It doesnt help to change the encoding inside the IDE, so I guess its something different.

      The interesting part is that when I let him point the same code to my Mac OS Couchbase Server 2.0 instance, the message comes back perfectly fine. I've never seen this on mac/linux before.

      So my question is first: is there anything that is different on Windows in terms of encoding and such that makes a difference here? So Win client -> Win server breaks, Win client -> Mac server works.

      I'll attach a screenshot from him to show what it looks like. It comes up when you use getStatus().getMessage() on a async operation.

      Thanks,
      Michael

      # Subject Project Status CR V
      For Gerrit Dashboard: &For+MB-8149=message:MB-8149

        Activity

        Hide
        trond Trond Norbye added a comment -

        The error function passed a stack buffer for transfer which seemed extremely likely to be the root cause here. It has been fixed in http://review.couchbase.org/#/c/28388/

        Show
        trond Trond Norbye added a comment - The error function passed a stack buffer for transfer which seemed extremely likely to be the root cause here. It has been fixed in http://review.couchbase.org/#/c/28388/
        Hide
        siri Sriram Melkote added a comment -

        Note that the message seems to have lot of \u0000, so it may be that we encoded 0's as a string for some reason

        Show
        siri Sriram Melkote added a comment - Note that the message seems to have lot of \u0000, so it may be that we encoded 0's as a string for some reason
        Hide
        ingenthr Matt Ingenthron added a comment -

        I'm assigning this to Trond, raising it to critical and re-adding 2.2 per a discussion with Ravi. The concern here is that if we have garbage or invalid encoding in error messages, what else has garbage/invalid encoding.

        Trond: the request here is to inspect the path to try to find any possible causes. We hope it's just a simple problem with string encoding. Please check with Michael if additional info is needed.

        Show
        ingenthr Matt Ingenthron added a comment - I'm assigning this to Trond, raising it to critical and re-adding 2.2 per a discussion with Ravi. The concern here is that if we have garbage or invalid encoding in error messages, what else has garbage/invalid encoding. Trond: the request here is to inspect the path to try to find any possible causes. We hope it's just a simple problem with string encoding. Please check with Michael if additional info is needed.
        Hide
        siri Sriram Melkote added a comment -

        I looked at this briefly before the VM got stopped (due to too low a price) on EC2. There didn't seem to be anything wrong from ns_server - either the message from memcached was wrong, or the buffer was being decoded wrongly by the client. In any case, since I'm not the correct person for ns_server (Alk), memcached (Mike) or the client (Michael), I'm reassigning rather than sit on this any longer for lack of time.

        Show
        siri Sriram Melkote added a comment - I looked at this briefly before the VM got stopped (due to too low a price) on EC2. There didn't seem to be anything wrong from ns_server - either the message from memcached was wrong, or the buffer was being decoded wrongly by the client. In any case, since I'm not the correct person for ns_server (Alk), memcached (Mike) or the client (Michael), I'm reassigning rather than sit on this any longer for lack of time.
        Hide
        daschl Michael Nitschinger added a comment -

        Assigning back to you for investigations!

        Show
        daschl Michael Nitschinger added a comment - Assigning back to you for investigations!

          People

          • Assignee:
            trond Trond Norbye
            Reporter:
            daschl Michael Nitschinger
          • Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes