Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0beta2
    • Fix Version/s: None
    • Component/s: None
    • Security Level: Public
    • Labels:
      None

      Description

      I'm marking this as critical because many folks seem to frown upon the high delays (read http connection latency) when establishing a new couchbase client.

      In this case, this would be a constructor option available for lcb_create which will accept an opaque 'map file'. This 'map file' will really just be a dump of a vbucket configuration. What makes this different from compat mode is that the clients will bootstrap when a network error or timeout occurs.

      However in the normal model of spawn -> mc operation, where the cluster config is fairly static, there is no need for the latency induced by an extra http connection.

      We'd need to implement file-locking semantics to write to this file (we'd maybe just ask for a path to read/write the config to/from, perhaps checking the timestamp, too).. as we'd have multiple clients trying to read/write to this. This is simple enough in Unix

      This is in conjunction with a different discussion regarding how to best handle re-bootstrapping, where it was suggested that we really don't need the bootstrap connection in the first place.

      There are inherent risks involved with this approach, for example, if one specifies the wrong nodes, then we only know about this during the re-bootstrap.

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

        Activity

        Hide
        ingenthr Matt Ingenthron added a comment -

        I'm certainly not opposed to this idea, but I'm not sure about it being at the critical level. I do think it'd have to be portable though.

        Sergey, what do you think? Is this a hotly needed feature?

        Show
        ingenthr Matt Ingenthron added a comment - I'm certainly not opposed to this idea, but I'm not sure about it being at the critical level. I do think it'd have to be portable though. Sergey, what do you think? Is this a hotly needed feature?
        Hide
        avsej Sergey Avseyev added a comment -

        Frankly speaking I don't understand the benefit from dumping some configuration to the disk. It might be better to implement lcb_reconnect() and in this case the user just won't destroy lcb_t internal structs and reuse previous in-memory config.

        Show
        avsej Sergey Avseyev added a comment - Frankly speaking I don't understand the benefit from dumping some configuration to the disk. It might be better to implement lcb_reconnect() and in this case the user just won't destroy lcb_t internal structs and reuse previous in-memory config.
        Hide
        mnunberg Mark Nunberg added a comment -

        This is for performance enhancements, it's not directly related to failures, but can increase speed for some use cases dramatically, as it cuts out a lot of latency.

        The idea is that the node map is static, so we don't need to have the initial HTTP connection.

        If you really want to be inventive, this can also use POSIX IPC instead of actual 'disk' (i.e. define a common shm path). The idea here in any event is to not depend so heavily on the REST connection in normal non-failure situations.

        Show
        mnunberg Mark Nunberg added a comment - This is for performance enhancements, it's not directly related to failures, but can increase speed for some use cases dramatically, as it cuts out a lot of latency. The idea is that the node map is static, so we don't need to have the initial HTTP connection. If you really want to be inventive, this can also use POSIX IPC instead of actual 'disk' (i.e. define a common shm path). The idea here in any event is to not depend so heavily on the REST connection in normal non-failure situations.
        Hide
        ingenthr Matt Ingenthron added a comment -

        While I think this makes sense, I do believe it can be deferred.

        Show
        ingenthr Matt Ingenthron added a comment - While I think this makes sense, I do believe it can be deferred.
        Hide
        ingenthr Matt Ingenthron added a comment -

        Let's see about this in the near future Sergey. We can discuss in our next sync up.

        Show
        ingenthr Matt Ingenthron added a comment - Let's see about this in the near future Sergey. We can discuss in our next sync up.
        Hide
        mnunberg Mark Nunberg added a comment -

        While opened a while back, this has largely been accomplished by the configuration cache feature

        Show
        mnunberg Mark Nunberg added a comment - While opened a while back, this has largely been accomplished by the configuration cache feature

          People

          • Assignee:
            avsej Sergey Avseyev
            Reporter:
            mnunberg Mark Nunberg
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Gerrit Reviews

              There are no open Gerrit changes