| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Reduce log level from error to warning for update inconsistency message
|
| |
| |
| |
| |
| |
| | |
`error` level is for the "node is on fire and falling down an elevator
shaft" type of messages, not for operation inconsistencies. Reduce
to `warning` accordingly.
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Only skip deactivating buckets if the entire _node_ is marked as
maintenance state, i.e. the node has maintenance state across all
bucket spaces provided in the bundle. Otherwise treat the state
transition as if the node goes down, deactivating all buckets.
Also ensure that the bucket deactivation logic above the SPI is
identical to that within Proton. This avoids bucket DBs getting
out of sync between the two.
|
| |
|
| |
|
|
|
|
| |
[run-systemtest]"
|
|
|
|
|
|
|
|
|
|
|
| |
Only skip deactivating buckets if the entire _node_ is marked as
maintenance state, i.e. the node has maintenance state across all
bucket spaces provided in the bundle. Otherwise treat the state
transition as if the node goes down, deactivating all buckets.
Also ensure that the bucket deactivation logic above the SPI is
identical to that within Proton. This avoids bucket DBs getting
out of sync between the two.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
bucket before waiting for the replies.
Prepare RemoveResult to contain more replies.
|
| |
|
| |
|
|
|
|
|
|
| |
* Add `from_distributor()` utility function to `MergeBucketCommand`
* Simplify boolean expression by moving sub-expression to own statement
* Improve wording of config parameter
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Historically the MergeThrottler component has required a deterministic
forwarding of merges between nodes in strictly increasing distribution
key order. This is to avoid distributed deadlocks caused by ending up
with two or more nodes waiting for each other to release merge resources,
where releasing one depends on releasing the other. This works well,
but has the downside that there's an inherent pressure of merges towards
nodes with lower distribution keys. These often become a bottleneck.
This commit lifts this ordering restriction, by allowing forwarded,
unordered merges to immediately enter the active merge window. By doing
this we remove the deadlock potential, since nodes will longer be waiting
on resources freed by other nodes.
Since the legacy MergeThrottler has a lot of invariant checking around
strictly increasing merge chains, we only allow unordered merges to be
scheduled towards node sets where _all_ nodes are on a Vespa version
that explicitly understands unordered merges (and thus do not self-
obliterate upon seeing one). To communicate this, full bucket fetches
will now piggy-back version-specific feature sets as part of the response
protocol. Distributors then aggregate this information internally.
|
|
|
|
|
|
|
|
|
|
|
| |
This was a feature tracing its lineage back to ye olde VDS days where we
had a dusty root drive holding the OS and Vespa and a dozen spinning rust
drives storing the actual data. The health ping would confirm that the
root drive was still functioning properly by triggering a write to it,
as the node would swiftly bail if any of the I/O operations failed.
Today's access patterns are wildly different so we'll detect disk problems
quickly anyway, not to mention Vespa Cloud has disk health monitoring built in.
|
|
|
|
|
| |
- Include header file for atomic when needed.
- Use normal function template instead of abbreviated function template.
|
| |
|
|
|
|
| |
longer needed.
|
|\
| |
| |
| |
| | |
vespa-engine/toregge/handover-tracker-to-apply-bucket-diff-state-on-exceptions
Handover tracker to ApplyBucketDiffState on exceptions.
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
vespa-engine/vekterli/prioritize-forwarded-merges-in-throttler-queue
Prioritize forwarded merges in MergeThrottler queue
|
| |
| |
| |
| |
| |
| |
| | |
Rationale: merges that already are part of an active merge window
are taking up logical resources on one or more nodes in the cluster
and we should prefer completing these before starting new merges
queued from distributors.
|
|/
|
|
|
|
|
| |
bucket doesn't exist:
* getBucketInfo() returns success with empty bucket info
* createIterator() returns success
* iterate() returns empty complete result.
|
|\
| |
| |
| |
| | |
vespa-engine/toregge/delay-apply-bucket-diff-state-deletion-try-2
Delay deletion of ApplyBucketState.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
ignored anyway, and no later operations depends on the outcome. In addition they are sequenced as the master executor conducts all operation in fifo order.
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/toregge/delay-replies-for-async-apply-bucket-diff
Delay replies for async apply bucket diff.
|
| |
| |
| |
| | |
pointing to the same reply.
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/toregge/update-merge-latency-metrics-from-operation-complete-callbacks
Update merge handler put/remove latency metrics from operation complete callback.
|
| |
| |
| |
| | |
callback.
|