| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| |
| |
| | |
vespa-engine/hakonhall/some-optimizations-of-rpcservertest
Some optimizations of RpcServerTest
|
| | |
|
|\ \
| | |
| | | |
Prepare to use ContainerPaths
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
Container config improvements [run-systemtest]
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- An initial value of 0, generated config generation sequence
1,1,2,3,... causing an exception in
Container.getConfigAndCreateGraph when it got bootstrap
configs with generation=1 twice.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Retrive bootstrap snapshot first when the system is in the
stable state. When bootstrap is newer than components,
retrieve the new components generation. This avoids getting
exceptions from the config system when a component that
takes a config with missing default value has been removed.
- Do not close set up empty component subscriber after bootstrap,
should be unnecessary as it's always done when component config
keys are changed.
- Declare getConfigsOnce private.
- Improve debug logging
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Cleanup, no functional changes
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Upgrade to Curator 5.2.0 [run-systemtest]
|
| | |_|/ /
| |/| | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
vespa-engine/hmusum/application-package-maintainer-changes
Improve download of application package in maintainer [run-systemtest]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Set downloadFromOtherSourceIfNotFound to false, so that the receiving config server
that gets the request don't try to download a file reference. This will be
done by the ApplicationPackageMaintainer on the other server anyway.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Prevent division by zero
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
metrics-proxy/src/main/java/ai/vespa/metricsproxy/service/SystemPoller.java
|
| | | | | | |
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | |
| | | | | |
| | | | | | |
vespa-engine/vekterli/add-distributor-enhanced-maintenance-scheduling-feature-flag
Add feature flag for enhanced distributor maintenance scheduling
|
| | |/ / /
| |/| | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
vespa-engine/vekterli/add-metric-for-max-time-since-bucket-gc
Add metric for max time since bucket GC was last run
|
| | |_|_|/
| |/| | |
| | | | |
| | | | |
| | | | |
| | | | | |
Max time is aggregated across all buckets. If this metric value grows
substantially larger than the configured GC period it indicates that
GC is being starved.
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
vespa-engine/toregge/add-detailed-metrics-for-failed-merge-operations
Add detailed metrics for failed merge operations.
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| |_|/ / /
|/| | | |
| | | | |
| | | | | |
vespa-engine/vekterli/avoid-stalling-maintenance-scheduling-if-single-op-blocked
Don't let a blocked maintenance operation inhibit remaining maintenance queue [run-systemtest]
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
We consider bucket maintenance so latency critical that we'll prefer
to stall scheduling of subsequent buckets instead of risking having
to re-scan the DB to encounter the bucket again.
|
| | | | | |
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The old maintenance scheduler behavior is to only remove a bucket from the
priority DB if its maintenance operation was successfully started. Failing
to start an operation could happen from both max pending throttling as well
as operation/bucket-specific blocking behavior. Since the scheduler would
encounter the same bucket as the one previously blocked upon its next tick
invocation, a single blocked bucket would run the risk of head-of-line
stalling the rest of the remaining maintenance queue (assuming the ongoing
DB scan did not encounter any higher priority buckets).
This commit changes the following aspects of maintenance scheduling:
* Always clear entries from the priority DB before trying to start an
operation. A blocked operation will be retried the next time the
regular bucket DB scan encounters the bucket.
* Avoid trying to start (and clear) inherently doomed operations by
_not_ trying to schedule any operations if it would be blocked due
to too many pending maintenance operations anyway. Introduces a
new `PendingWindowChecker` interface for this purpose.
* Explicitly inhibit all maintenance scheduling if a pending cluster
state is present. Operations are already _implicitly_ blocked from
starting if there's a pending cluster state, but this would cause
the priority DB from being pointlessly cleared.
|
|\ \ \ \
| |_|/ /
|/| | | |
Balder/test system metrics
|
| | | | |
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
vespa-engine/hakonhall/reduce-running-time-of-masterelectiontest-from-28-to-12s
Reduce running time of MasterElectionTest from 28 to 12s
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Stop reading container images from ZK
|