| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
| |
better generated code.
|
|\
| |
| |
| |
| | |
vespa-engine/balder/bring-you-backing-buffer-along
Balder/bring your backing buffer along
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create-if-missing updates have a rather finicky behavior in the backend,
wherein they'll set the timestamp of the previous document to that of the
_new_ document timestamp if the update ended up creating a document from
scratch. This particular behavior confuses the "after the fact" timestamp
consistency checks, since it will seem like the document that was created
from scratch is a better candidate to force convergence towards rather
than the ones that actually updated an existing document.
With this change we therefore detect this case specially and treat the
received timestamps as if the document updated had a timestamp of zero.
This matches the behavior of regular (non auto-create) updates.
Note that another venue for solving this would be to alter the returned
timestamp in the backend to be zero instead, but this would cause issues
during rolling upgrades since some of the content nodes would be returning
zero timestamps while others would be returning non-zero. This would in
turn trigger false positives for the inconsistency sanity checks.
Also note that this is a fallback path that should not be hit unless
the a-priori inconsistency checks in the two-phase update operation
somehow fails to recognize that the document versions may be out of
sync.
This relates to issue #11686
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/support-config-disabling-of-merges
Support config disabling of merges
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
If config is set, all merges will be completely inhibited. This is
useful for letting system tests operate against a bucket replica state
that is deterministically out of sync.
This relates to issue #11686
|
|\ \
| | |
| | |
| | |
| | | |
vespa-engine/toregge/system-time-and-steady-time-might-have-different-duration-types
std::chrono::system_clock and std::chrono::steady_clock might have different duration types.
|
| | | |
|
| |/ |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introducing a new member in the category "stupid bugs that I should have
added explicit tests for when adding the feature initially".
There was ambiguity in the GetOperation code where a timestamp sentinel
value of zero was used to denote not having received any replies yet,
but where a timestamp of zero also means "document not found on replica".
This means that if the first reply was from a replica _without_ a document
and the second reply was from a replica _with_ a document, the code
would act as if the first reply effectively did not exist. Consequently
the Get operation would be tagged as consistent. This had very bad
consequences for the two-phase update operation logic that relied on
this information to be correct.
This change ensures there is no ambiguity between not having received
a reply and having a received a reply with a missing document.
|
|
|
|
|
|
|
|
|
|
| |
Even with the fix in #11561 we are still observing replica
divergence warnings in the logs. Disabling this feature entirely
until the issue has been fully investigated and a complete fix
has been implemented.
Also emit a log message when the distributor has forced convergence
of a detected inconsistent update.
|
|\ |
|
| |
| |
| |
| | |
extracting debuginfo.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After the recent change to allow safe path updates to be restarted
as fast path updates iff all observed document timestamps are equal,
a race condition regression was introduced. If the bucket that the
update operation was scheduled towards got a new replica concurrently
created _between_ the time that safe path Gets were sent and received,
it was possible for updates to be sent to inconsistent replicas. This
is because the Get and Update operations use the current database
state at _their_ start time, not a stable snapshot state from the start
time of the two phase update operation itself.
Add an explicit check that the replica state between sending Gets and
Updates is unchanged. If it has changed, a fast path restart is _not_
permitted.
|
|\
| |
| |
| |
| | |
vespa-engine/balder/use-duration-in-messagebus-and-storageapi-rebased-1
timeout as duration
|
| |\
| | |
| | |
| | | |
balder/use-duration-in-messagebus-and-storageapi-rebased-1
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Conflicts:
messagebus/src/vespa/messagebus/testlib/testserver.cpp
|
|\ \ \
| |_|/
|/| | |
Balder/use system time in trace
|
| |/ |
|
|/
|
|
|
| |
Renamed Timer -> ScheduledExecutor.
Do not include thread.h when not needed in header files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When Get requests initiated outside the main distributor thread are sent
via the MessageSender that is implemented by the main Distributor instance,
they would be implicitly registered with the pending message tracker.
Not only was this thread unsafe, the registrations would never be cleared
away since the reply pipeline bypassed it entirely. This would cause a silent
memory leak that would build up many small allocations over time.
We now dispatch Get requests directly through the storage link chain, bypassing
the message tracking component. This both fixes the leak and avoids extra
overhead for the Get requests.
Note: the concurrent Get feature is _not_ enabled by default.
Also fixes an issue where concurrent Get operations weren't correctly
gracefully aborted when the node shuts down.
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/defer-gc-bucket-info-merge-until-all-responses-received
Defer GC bucket info merge until all responses have been received
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Avoids causing false positives in the merge pending metrics due to
partial (and mismatching) bucket info being merged into the DB one
by one as responses are received. Instead, wait until all responses
have been received and merge as one atomic operation.
This fixes #11373
|
|\ \ |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in sync
When a bucket has replicas with mismatching metadata (i.e. they are out of sync),
the distributor will initiate a write-repair for updates to avoid divergence of
replica content. This is done by first sending a Get to all diverging replica
sets, picking the highest timestamp and applying the update locally. The updated
document is then sent out as a Put. This can be very expensive if document Put
operations are disproportionally more expensive than partial updates, and also
makes the distributor thread part of a contended critical path.
This commit lets `TwoPhaseUpdateOperation` restart an update as a "fast path"
update (partial updates sent directly to the nodes) if the initial read phase
returns the same timestamp for the document across all replicas.
It also removes an old (but now presumed unsafe) optimization where Get
operations are only sent to replicas marked "trusted" even if others are
out of sync with it. Since trustedness is a transient state that does not
persist across restarts or bucket handoffs, it's not robust enough to be
used for such purposes. Gets will now be sent to all out of sync replica
groups regardless of trusted status.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Avoids O(n) explicit inserts in favor of a bulk load.
|
|
|
|
| |
Currently only used for code paths touched by Get operations.
|
|
|
|
| |
Requires _both_ B-tree DB to be used _and_ stale reads to be enabled.
|