Permalink
Commits on Jan 12, 2017
  1. JVMCBC-383: Redistribute BucketConfigRequest if hostname not set.

    Motivation
    ----------
    If the BucketConfigRequest does not have a hostname explicitly
    attached (which is needed during bootstrap), the code should
    apply the usual round-robin approach to make sure that even
    if a node is down the config message succeeds eventually.
    
    Modifications
    -------------
    The code is modified so that a BucketConfigRequest without
    a hostname just goes through the same round-robin approach
    as other config messages. Previously, always the same node
    would've been used so up-the-stack retry mechanisms were
    fruitless since the same node would be tried over and over
    again for the BucketConfigRequest.
    
    Test has been added to assert this.
    
    Result
    ------
    The BCR can be properly dispatched, even when a node is
    down.
    
    Change-Id: I99cc53ec3e561668435af9e7e2ff908a7be0c249
    Reviewed-on: http://review.couchbase.org/71898
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
    Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
    daschl committed Jan 12, 2017
Commits on Jan 11, 2017
  1. JVMCBC-381: No keepalive for non-pipelined endpoints when op is in-fl…

    …ight
    
    Motivation
    ----------
    On non-pipelined endpoints it is important to not send keepalives when an
    operation is in-flight, since sending the keepalive has the same effect
    as pipelining another op over that socket, leading to prematurely termination
    of the previous query.
    
    Modifications
    -------------
    The AGH has been modified to only initiate the keepalive sending process if
    either pipelining is enabled (then we always send it) or otherwise no operation
    is either queued in the sentRequestQueue or currently being decoded. This
    is similar to the check previously added on regular ops under non-pipelining.
    
    Result
    ------
    Pipelining does not implicitly occur on non-pipeline enabled endpoints with
    keepalives.
    
    Change-Id: I2b660895e6548464c5e28f09195b4083838eaaa0
    Reviewed-on: http://review.couchbase.org/71800
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
    Reviewed-by: Subhashni Balakrishnan <b.subhashni@gmail.com>
    daschl committed Jan 10, 2017
  2. JVMCBC-380: Disable pipelining for HTTP services.

    Motivation
    ----------
    In forum posts as well as other tickets it has been discovered that
    the implicit pipelining netty/core-io uses doesn't work well with
    the go implementation of pipelining in http 1.1. In fact, it doesn't
    work at all and leads to all kinds of weird issues, especially
    prematurely aborted (n1ql) requests that return 0 as the result count.
    
    As a result, we need to disable pipelining for HTTP based services,
    but for performance reasons keep it for binary ops.
    
    Modifications
    -------------
    This change adds a short-circuit statement to the AbstractGenericHandler
    which, if the endpoint is set to "pipeline" keeps going forward but
    otherwise checks if a request is already in-flight and if so it sends
    it into the usual retry-or-cancel circle.
    
    Note that in-flight can either mean outstanding requests in the queue
    but also currently processing/decoding one which has already been
    taken out of the request queue.
    
    Each endpoint is modified to pass in a true/false flag if pipelining
    should be enabled for it. Tests have been modified to take that flag
    into account and also for each endpoint suitable regression tests
    have been added to make sure we don't start pipelining in the future.
    
    Result
    ------
    Pipelining is now for all HTTP-based endpoints disabled. This also
    includes the VIEW service which is erlang based and is not known
    to cause issues here, but lets keep it consistent.
    
    Change-Id: Ie50f62fb3f90dc5c9305e25483995af534796529
    Reviewed-on: http://review.couchbase.org/71795
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
    daschl committed Jan 10, 2017
Commits on Jan 5, 2017
  1. Start 1.4.1 Development

    Change-Id: Id40d583e17973fd6b71d248572a38351742f1eb2
    Reviewed-on: http://review.couchbase.org/71597
    Reviewed-by: Michael Nitschinger <michael@nitschinger.at>
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    daschl committed Jan 5, 2017
  2. Prepare 1.4.0 Release

    Change-Id: Id36b6657116caed5766d708ceee22e48a024349c
    Reviewed-on: http://review.couchbase.org/71589
    Reviewed-by: Michael Nitschinger <michael@nitschinger.at>
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    daschl committed Jan 5, 2017
Commits on Jan 2, 2017
  1. JVMCBC-378: Support for optional IO pool per service.

    Motivation
    ----------
    In certain cases it has been found that segregating the IO
    event loops for different services provides better performance
    since they don't disturb each other. This is especially true
    when short-lived but many KV operations interleave with longer
    running N1QL or view queries.
    
    Modifications
    -------------
    This changeset makes it possible to optionally plug in different
    event loop groups for different services. If none are provided
    the default ioPool is used as before to make sure its 100%
    backwards compatible.
    
    If a custom event loop group is passed in the hook lifecycle works
    as with the general ioLoop one.
    
    Result
    ------
    It is now possible to configure one Environment to segregate different
    services into different event loops for better performance without
    having to create different environments.
    
    Change-Id: I526cbb1e269fc84f8f13f3809439b721fdcb85f2
    Reviewed-on: http://review.couchbase.org/70867
    Reviewed-by: Sergey Avseyev <sergey.avseyev@gmail.com>
    Tested-by: Michael Nitschinger <michael@nitschinger.at>
    daschl committed Dec 12, 2016