History log of /6.6.0/kv_engine/tests/mcbp/mcbp_frame_extra.cc (Results 1 - 6 of 6)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v7.0.2, v6.6.3, v7.0.1, v7.0.0, v6.6.2, v6.5.2, v6.6.1, v6.0.5, v6.6.0, v6.5.1, v6.0.4, v6.5.0, v6.0.3
# f9fd16f1 05-Sep-2019 Trond Norbye <trond.norbye@gmail.com>

Flip the logic for Reorder bit to Barrier

Clients want to be able to set "unordered executions" as the
new default, and they don't provide any guarantees about
execution order today

Flip the logic for Reorder bit to Barrier

Clients want to be able to set "unordered executions" as the
new default, and they don't provide any guarantees about
execution order today (a change in the cluster topology
could already reorder the commands for the same key)

If the client enables unordered execution for a connection,
the server is permitted to choose the execution order for
all commmands on the connection (except for commands with
a barrier bit set).

Change-Id: I26f3af7e831333ff8c1b41e1d3e45b3137ae0106
Reviewed-on: http://review.couchbase.org/114329
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...


# 1b818779 24-Jun-2019 Trond Norbye <trond.norbye@gmail.com>

Add cb::mcbp::is_reorder_supported

And update the documentation with a list of the commands to
be supported initially.

According to the spec we'll silently ignore the reorder at

Add cb::mcbp::is_reorder_supported

And update the documentation with a list of the commands to
be supported initially.

According to the spec we'll silently ignore the reorder attribute
for "unsupported" commands, but execute them in order.

Change-Id: I3a5d53dc3fc2ddd706e02a4deff9d7b2a1cd750c
Reviewed-on: http://review.couchbase.org/111087
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Jim Walker <jim@couchbase.com>

show more ...


# 7240e771 03-May-2019 Dave Rigby <daver@couchbase.com>

MB-34027 [SR]: Implement default timeout

For SyncWrite requests which don't specify a timeout, a
server-provided timeout should be applied to the request.

Add support for this -

MB-34027 [SR]: Implement default timeout

For SyncWrite requests which don't specify a timeout, a
server-provided timeout should be applied to the request.

Add support for this - when a SyncWrite is added to the
ActiveDurabiltyMonitor, if the requests' durability requirements
specify a default timeout then apply a value - currently 30s.

Add a new cb::durability::Timeout class to implement this, which
enforces the two special values the timeout can have:

- BucketDefault: Use the default timeout value the bucket is
configured with.
- Infinite: Don't use any timeout value (wait forever).

Note that Infinite is used internally (for example after Warmup /
replica promotion were we _must_ wait for prepared SyncWrites to
complete), but is not valid for clients to specify.

Similary BucketDefault should only be specified by a client via
omitting the timeout field - an explcit timeout value of '0' is
invalid.

Change-Id: Ic4850f35b44307ccadba89145c8a4a589b089754
Reviewed-on: http://review.couchbase.org/108656
Reviewed-by: Ben Huddleston <ben.huddleston@couchbase.com>
Tested-by: Build Bot <build@couchbase.com>

show more ...


Revision tags: v5.5.4, v5.5.5
# 04c1c8ec 20-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

Remove config.h

Change-Id: I79eb8c762971255db9d36a5f6461a8a6d0f29249
Reviewed-on: http://review.couchbase.org/106517
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave

Remove config.h

Change-Id: I79eb8c762971255db9d36a5f6461a8a6d0f29249
Reviewed-on: http://review.couchbase.org/106517
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


Revision tags: v5.5.6
# c2412559 26-Feb-2019 Trond Norbye <trond.norbye@gmail.com>

MB-33226: OpenTracing prototype

This prototype allows you to hook into the OpenTracing
framework by having the client supply the parent span
context by using a new FrameInfo field in

MB-33226: OpenTracing prototype

This prototype allows you to hook into the OpenTracing
framework by having the client supply the parent span
context by using a new FrameInfo field in the header,
and the server adds the new spans by referencing that
as the parent.

It is configured through memcached.json in a new
section named "opentracing" which looks like:

"opentracing": {
"enabled": true,
"module": "/opt/jaeger/lib/libjaegertracing.so.0.5.0",
"config": "service_name: Couchbase"
}

"enabled" is an on/off switch which may be toggled
at any time. If set to false the server silently
ignores any trace contexts provided in the request.

"module" contains the absolute path to a shared
library containing an implementation of the
OpenTracing API. This parameter may be changed at
any time, but once successfully loaded any change
in the parameter is ignored (the library will only
be loaded if enabled is also set to true).

"config" contains the configuration parameter
to pass on to the module when we try to create
the tracer. It parameter may be changed at any
time, but it is silently ignored if changed after
the module is successfully loaded.

See scripts/opentracing.sh for how to set the
parameters above.

Limitations:

Given that this is just a prototype it has a number
of limitations and shortcommings:

* No privilege support
Clients should hold a privilege in order to enable
tracing as it puts extra load on the server

* Integration with the tracer happens in the front
end worker threads. It is not defined in the
OpenTracing API if the calls may block or not.

* No relasionships with the stacked spans. All
spans in the server is put directly under the
client span.

* Limited information in each span. No effort
was put into figuring out if we could add more
context to the various spans.

Change-Id: I87506f36903f6dcd470c85abfb2c778c0f304ad6
Reviewed-on: http://review.couchbase.org/105383
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>

show more ...


# 50b6ead0 06-Mar-2019 Trond Norbye <trond.norbye@gmail.com>

Refactor: Remove validation in request::parseFrameExtras

The validation is performed in the package validation
(and added unit tests to ensure that we actually do
test and return the

Refactor: Remove validation in request::parseFrameExtras

The validation is performed in the package validation
(and added unit tests to ensure that we actually do
test and return the correct error message)

Change-Id: I829d4b8986264e21bb09df66a2799979f7525488
Reviewed-on: http://review.couchbase.org/105782
Tested-by: Build Bot <build@couchbase.com>
Reviewed-by: Dave Rigby <daver@couchbase.com>
Reviewed-by: Paolo Cocchi <paolo.cocchi@couchbase.com>

show more ...