Add the capability to turboload segments onto historicals by adarshsanjeev · Pull Request #17775 · apache/druid

adarshsanjeev · 2025-03-04T05:24:06Z

Add the capability to set Historicals into a turbo loading mode, to focus on loading segments at the cost of query performance.

Context

Currently, when a new Historical is started, it initially starts out using a bootstrap thread pool It uses this thread pool to load any existing cached segments and broadcast segments. Once it loads any segments from both these sources, the historical switches to a smaller segment loading threadpool and begins to serve queries.

In certain cases, it would be useful to have the historical switch back to this mode, and focus on loading segments, either to continue loading the initial non-bootstrap segments, or to catch up with assigned segments.

This PR adds a coordinator dynamic config that allows servers to be configured to use the larger bootstrap threadpool to load segments faster.

Release Notes

Added a new dynamic coordinator configuration, turboLoadingNodes. Servers in this list will load using their bootstrap threadpool. This will load the segments faster at the cost of query performance. For servers specified in turboLoadingNodes, druid.coordinator.loadqueuepeon.http.batchSize is ignored and the coordinator uses the value of the respective numLoadingThreads instead.

This PR has:

This reverts commit c9a9fd5.

maytasm · 2025-03-04T05:30:58Z

One thing I noticed is that when you have the cluster starting up, the historical will not / can not serve any query until all the segments are loaded (I think there is a config for this which is enabled by default). In this case, we should always use turboLoadHistoricals (by default), since the historical cannot serve query anyway.

kfaraz · 2025-03-04T05:54:11Z

One thing I noticed is that when you have the cluster starting up, the historical will not / can not serve any query until all the segments are loaded (I think there is a config for this which is enabled by default). In this case, we should always use turboLoadHistoricals (by default), since the historical cannot serve query anyway.

@maytasm , IIUC, you are referring to the bootstrap segments, which includes broadcast segments and segments already present on the historical disk.
For these bootstrap segments, we already use the turbo loading thread pool.

The change here allows to optionally put a historical in turbo mode to load non-bootstrap segments, i.e. segments assigned later by the coordinator.

kfaraz

Thanks a lot for the changes, @adarshsanjeev ! This will be very helpful for cluster upgrades.

I have done a surface review and left some feedback.
Will take another deeper look today.

FrankChen021 · 2025-03-06T03:11:18Z

One thing I noticed is that when you have the cluster starting up, the historical will not / can not serve any query until all the segments are loaded (I think there is a config for this which is enabled by default). In this case, we should always use turboLoadHistoricals (by default), since the historical cannot serve query anyway.

@maytasm , IIUC, you are referring to the bootstrap segments, which includes broadcast segments and segments already present on the historical disk. For these bootstrap segments, we already use the turbo loading thread pool.

The change here allows to optionally put a historical in turbo mode to load non-bootstrap segments, i.e. segments assigned later by the coordinator.

But the description(the Context section) of this PR is different from what the changes really do. I think we need to update the description of the PR to eliminate misleading.

kgyrtkirk · 2025-03-07T10:21:06Z

        Executors.newScheduledThreadPool(
            config.getNumLoadingThreads(),
            Execs.makeThreadFactory("SimpleDataSegmentChangeHandler-%s")


its unclear to me why the need for a second executor pool; it would be possibly better to use a more aggressively tuned threadpool first and then go back to using a more conservative one.

The usage of Executors.newScheduledThreadPool is kinda unfortunate as it will retain all these threads forever; a ThreadPoolExecutor with allowCoreThreadTimeOut could go back to 0 threads if not in use

Modified the threadpools to time out core threads as well, and added a new scheduled threadpool to handled the scheduled stuff, is this what you had in mind?

vtlim

Left some comments on the docs

vtlim · 2025-03-11T18:13:38Z

 |`decommissioningNodes`|List of Historical servers to decommission. Coordinator will not assign new segments to decommissioning servers, and segments will be moved away from them to be placed on non-decommissioning servers at the maximum rate specified by `maxSegmentsToMove`.|none|
 |`pauseCoordination`|Boolean flag for whether or not the Coordinator should execute its various duties of coordinating the cluster. Setting this to true essentially pauses all coordination work while allowing the API to remain up. Duties that are paused include all classes that implement the `CoordinatorDuty` interface. Such duties include: segment balancing, segment compaction, submitting kill tasks for unused segments (if enabled), logging of used segments in the cluster, marking of newly unused or overshadowed segments, matching and execution of load/drop rules for used segments, unloading segments that are no longer marked as used from Historical servers. An example of when an admin may want to pause coordination would be if they are doing deep storage maintenance on HDFS name nodes with downtime and don't want the Coordinator to be directing Historical nodes to hit the name node with API requests until maintenance is done and the deep store is declared healthy for use again.|false|
 |`replicateAfterLoadTimeout`|Boolean flag for whether or not additional replication is needed for segments that have failed to load due to the expiry of `druid.coordinator.load.timeout`. If this is set to true, the Coordinator will attempt to replicate the failed segment on a different historical server. This helps improve the segment availability if there are a few slow Historicals in the cluster. However, the slow Historical may still load the segment later and the Coordinator may issue drop requests if the segment is over-replicated.|false|
+|`turboLoadingNodes`|List of Historical servers to place in turbo loading mode. This causes the historical to load segments faster at the cost of query performance. For any performance increase, the runtime parameter `druid.coordinator.loadqueuepeon.http.batchSize` must not be configured. |none|


It's not immediately clear how turboLoadingNodes relates to batchSize. Does it mean that configuring batchSize with turboLoadingNodes impacts query performance worse than just turbo mode? Or does it mean that not configuring the batch size will lead to query performance increase when in turbo mode?

Attempted to clarify this. Please let me know if the wording is better now.

kfaraz

Overall approach looks good, left minor suggestions in multiple places.
Please let me know if anything needs further clarification.

kfaraz

Thanks for the update, @adarshsanjeev !
Left a few final suggestions.

The PR has been modified significantly since it was created. Could you please update the PR description accordingly?
Also, please add the details of cluster testing in the PR description.

kfaraz · 2025-03-22T04:15:29Z

+    if (batchSize < 1) {
+      log.error("Batch size must be greater than 0.");
+      throw new RE("Batch size must be greater than 0.");
+    }


We should retain the validation in this class but let's not throw an exception here.
The validation can move to calculateBatchSize method so that we always return a positive integer from there.

Also, please ensure that there are required validations in SegmentLoadingConfig and HttpLoadQueuePeonConfig around numLoadingThreads , numBootstrapThreads and batchSize respectively.

Is the idea to have validated configs so that we validate it on startup instead of when we need the config during runtime?

Looking at these config classes, that doesn't seem to be the convention, there is no validation for any other config, and some config classes SegmentLoaderConfig would require some refactor to have a constructor to do such validation on init.

Yes, configs should be validated on startup itself. There is not much use doing the validation and throwing an exception when we use the config values.

You can create a follow up PR to do the validation.

kfaraz

Thanks for the changes, @adarshsanjeev !

capistrant · 2025-03-28T22:28:50Z

@adarshsanjeev is there a particular reason that this new field in coordinator dynamic config wasn't added to the web-console form for the config, or could we add it as followup? Especially if this is going to be called out in Druid 33 release notes, it would be nice to have available in the form.

Add the capability to set Historicals into a turbo loading mode, to focus on loading segments at the cost of query performance. Context -------- Currently, when a new Historical is started, it initially starts out using a bootstrap thread pool. It uses this thread pool to load any existing cached segments and broadcast segments. Once it loads any segments from both these sources, the historical switches to a smaller thread-pool and begins to serve queries. In certain cases, it would be useful to have the historical switch back to this mode, and focus on loading segments, either to continue loading the initial non-bootstrap segments, or to catch up with assigned segments. This PR adds a coordinator dynamic config that allows servers to be configured to use the larger bootstrap threadpool to load segments faster. Changes --------- - Added a new dynamic coordinator configuration, `turboLoadingNodes`. - Ignore `druid.coordinator.loadqueuepeon.http.batchSize` for servers in `turboLoadingNodes` - Add API on historical to return loading capabilities i.e. num loading threads in normal and turbo mode

) * Some debug configs * use postgresql as the default metadata store and set a few debug log * Add s3 extension, update local storage directory, use emoji in website title * Update favicon, easier to find the console tab * Add indexer server, add some basic security config, updated historical and broker to use the common druid root directory * Some policy config * add checks for SegmentMetadataQuery * Add thread.sleep for flaky. * auth config * format, and remove temp folder rules * added NoopPolicyEnforcer and RestrictAllTablesPolicyEnforcer class * Support pushing and streaming task payload for HDFS (#17742) Implement pushTaskPayload/streamTaskPayload as introduced in #14887 for HDFS storage to allow larger mm-less ingestion payloads when using HDFS as the deep storage location. * Remove usages of deprecated API Files.write() (#17761) * Add deprecated com.google.common.io.Files#write to forbiddenApis * Replace deprecated Files.write() * Doc: Fix description typo for sqlserver metadata store (#17771) Mistakenly categories under deep storage instead of metadata store. * Fix binding of segment metadata cache on CliOverlord (#17772) Changes --------- - Bind `SegmentMetadataCache` only once to `HeapMemorySegmentMetadataCache` in `SQLMetadataStorageDruidModule` - Invoke start and stop of the cache from `DruidOverlord` rather than on lifecycle start/stop - Do not override the binding in `CliOverlord` * Docs: Remove semicolon from example (#17759) * Restrict segment metadata kill query till maxInterval from last kill task time (#17770) Changes --------- - Use `maxIntervalToKill` to determine search interval for killing unused segments. - If no segment has been killed for the datasource yet, use durationToRetain * Update the Supervisor endpoint to not restart the Supervisor if the spec was unmodified (#17707) Add an optional query parameter called skipRestartIfUnmodified to the /druid/indexer/v1/supervisor endpoint. Callers can set skipRestartIfUnmodified=true to not restart the supervisor if the spec is unchanged. Example: curl -X POST --header "Content-Type: application/json" -d @supervisor.json localhost:8888/druid/indexer/v1/supervisor?skipRestartIfUnmodified=true * Reduce noisy coordinator logs (#17779) * Emit time lag from Kafka supervisor (#17735) Changes --------- - Emit time lag from Kafka similar to Kinesis as metrics `ingest/kafka/lag/time`, `ingest/kafka/maxLag/time`, `ingest/kafka/avgLag/time` - Add new method in `KafkaSupervisor` to fetch timestamps of latest records in stream to compute time lag - Add new field `emitTimeLagMetrics` in `KafkaSupervisorIOConfig` to toggle emission of new metrics * fix processed row formatting (#17756) * Web console: add suggestions for table status filtering. (#17765) * suggest filter values when known * update snapshots * add more d * fix load rule clamp * better segment timeline init * Remove all usages of skife config (#17776) Changes --------- - Usages of skife config had been deprecated in #14695 and `LegacyBrokerParallelMergeConfig` is the last config class that still uses it. - Remove `org.skife.config` from pom, licenses, log4j2.xml, etc. - Add validation for deleted property paths in `StartupInjectorBuilder.PropertiesValidator` - Use the replacement flattened configs (which remove the `.task` and `.pool` substring) * Add field `taskLimits` to worker select strategies (#16889) Changes --------- - Add field `taskLimits` to the following worker select strategies `equalDistribution`, `equalDistributionWithCategorySpec`, `fillCapacityWithCategorySpec`, `fillCapacity` - Add sub-fields `maxSlotCountByType` and `maxSlotRatioByType` to `taskLimits` - Apply these limits per worker when assigning new tasks --------- Co-authored-by: sviatahorau <mikhail.sviatahorau@deep.bi> Co-authored-by: Benedict Jin <asdf2014@apache.org> Co-authored-by: Kashif Faraz <kashif.faraz@gmail.com> * remove NullValueHandlingConfig, NullHandlingModule, NullHandling (#17778) * Docs: Add SQL query example (#17593) * Docs: Add query example * Update after review * Update query * Update docs/api-reference/sql-api.md --------- Co-authored-by: Victoria Lim <vtlim@users.noreply.github.com> * More logging cleanup on Overlord (#17780) * Remove maven.twttr repo from pom (#17797) remove usage of dependency:go-offline from build scripts - as it tries to download excluded artifacts --------- Co-authored-by: Zoltan Haindrich <kirk@rxd.hu> * fix bug (#17791) * Log query stack traces for DEVELOPER and OPERATOR personas. (#17790) Currently, query stack traces are logged only when "debug: true" is set in the query context. This patch additionally logs stack traces targeted at the DEVELOPER or OPERATOR personas, because for these personas, stack traces are useful more often than not. We continue to omit stack traces by default for USER and ADMIN, because these personas are meant to interact with the API, not with code or logs. Skipping stack traces minimizes clutter in the logs. * Set useMaxMemoryEstimates=false for MSQ tasks (#17792) * Web console: fix go to task selecting correct task type (#17788) * fix go to task selecting correct task type * support autocompact also * support scheduled_batch, refactor * one more state and update tests * Enable ComponentSuppliers to run queries using Dart (#17787) Enables Calcite*Test-s and quidem tests to run queries with Dart. needed some minor tweaks: changed to use interfaces at some places renamed DartWorkerClient to DartWorkerClientImpl and made DartWorkerClient an interface reused existing parts of the MSQ test system to run the query * Fix single container config creates failing peon tasks (#17794) * Fix single container config creates failing peon tasks * More obvious array error output * Update `k8s-jobs.md` reference (#17805) Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com> * Footer Copyright Year Update (#17751) * Update docusaurus.config.js * Update docusaurus.config.js * [Revert] Reduce number of metadata transaction retries (#17808) * Revert "Run JDK 21 workflows with latest JDK. (#17694)" (#17806) * Revert "Run JDK 21 workflows with latest JDK. (#17694)" This reverts commit 31ede5c * Review comments. * Review comments. * Revert "reject publishing actions with a retriable error code if a earlier task is still publishing (#17509)" This reverts commit aca56d6. * Fix unstable tests after #17787 and dart usage in quidem-ut (#17814) * fixes * fix cleanup * Use "mix" shuffle spec for target size with nil clusterBy. (#17810) When a nil clusterBy is used, we have no way of achieving a particular target size, so we need to fall back to a "mix" spec (unsorted single partition). This comes up for queries like "SELECT COUNT(*) FROM FOO LIMIT 1" when results use a target size, such as when we are inserting into another table or when we are writing to durable storage. * Docs: Recommend using runtime property javaOptsArray instead of javaOpts * Add minor checks in jetty utils (#17817) Add minor checks in jetty utils class * CI improvement: Leverage cancelled() instead of always() for CI jobs (#17819) * Make MSQ tests use the same datasets as other similar tests (#17818) MSQ tests had their own way of creating the segments/etc - this have lead to that custom datasets didn't worked with them. This patch alters a few things to make it possible to access CompleteSegment for the active segments - which fixed the issue and also enabled the removal of the extra loading codes. * Add unnest tests to quidem (#17825) This PR adds the sql-native unnest tests to quidem. This set of tests has 6392 queries in total, with 5247 positive tests and 1145 negative tests. * Web console: show loader on aux queries (#17804) * show loader on aux queries * show supervisors if not on page 0 * refactor * fix bug fetching data when columns are added or removed * update test * Use compaction dynamic config to enable compaction supervisors (#17782) Changes --------- - Remove runtime property object `CompactionSupervisorConfig` - Add fields `useSupervisors` and `engine` to cluster-level compaction dynamic config - Remove unused field `useAutoScaleSlots` * Retry segment publish task actions without holding locks (#17816) #17802 reverted a retry of failed segment publish actions. This patch attempts to address the original issue by retrying the segment publish task actions on the client (i.e. task) side without holding any locks so that other transactions are not blocked. Changes Add retries to TransactionalSegmentPublisher Add field retryable to SegmentPublishResult Remove class DataStoreMetadataUpdateResult and use SegmentPublishResult instead * Add the capability to turboload segments onto historicals (#17775) Add the capability to set Historicals into a turbo loading mode, to focus on loading segments at the cost of query performance. Context -------- Currently, when a new Historical is started, it initially starts out using a bootstrap thread pool. It uses this thread pool to load any existing cached segments and broadcast segments. Once it loads any segments from both these sources, the historical switches to a smaller thread-pool and begins to serve queries. In certain cases, it would be useful to have the historical switch back to this mode, and focus on loading segments, either to continue loading the initial non-bootstrap segments, or to catch up with assigned segments. This PR adds a coordinator dynamic config that allows servers to be configured to use the larger bootstrap threadpool to load segments faster. Changes --------- - Added a new dynamic coordinator configuration, `turboLoadingNodes`. - Ignore `druid.coordinator.loadqueuepeon.http.batchSize` for servers in `turboLoadingNodes` - Add API on historical to return loading capabilities i.e. num loading threads in normal and turbo mode * Fix resource leak for GroupBy query merge buffer when query matched result cache (#17823) * Fix resource leak for GroupBy query merge buffer when match result cache * Fix resource leak for GroupBy query merge buffer when match result cache * Add test * Add test * Add comment * Add test * Add metric and simulation test for turbo loading mode (#17830) Changes --------- - Add field `loadingMode` to `SegmentChangeStatus` - Including loading mode in `DataSegmentChangeResponse` - Include loading mode in the `description` of metrics emitted from `HttpLoadQueuePeon` - Add simulation test to verify loading mode metrics * Update query example (#17811) * String util upgrade for jdk9+ (#17795) * Update StringUtils.replace() after fix in JDK9 * Upgrade optimized string replace algorithm * Update methods by re-using declared StringUtils#replace method * Replace hard-coded UTF-8 encodings with StandardCharsets * Documentation Fix (#17826) * Enable to run quidem tests against multiple configurations; add conditionals; cleanup framework init (#17829) * cleans up `SqlTestFramework` initialization to leave the `OverrideModule` empty - so that tests could more easily take over parts * remove the `QueryComponentSupplier#createEngine` factory method - instead uses a `Class<SqlEngine>` and use the `injector` to initialize it * enables the usage of `!disabled <supplier> <message>` - to mark cases which are not yet supported with a specific configuration for some reason * fixes that `datasets` was not respecting the `rollup` specification of the ingest * enables to use `MultiComponentSupplier` backed tests - these will turn into matrix tests over multiple componentsuppliers - enabling running the same testcase in different scenarios * Fix failing test in DimensionSchemaUtilsTest (#17832) * Improve performance of segment metadata cache on Overlord (#17785) Description ----------- #17653 introduces a cache for segment metadata on the Overlord. This patch is a follow up to that to make the cache more robust, performant and debug-friendly. Changes --------- - Do not cache unused segments This significantly reduces sync time in cases where the cluster has a lot of unused segments. Unused segments are needed only during segment allocation to ensure that a duplicate ID is not allocated. This is a rare DB query which is supported by sufficient indexes and thus need not be cached at the moment. - Update cache directly when segments are marked as unused to avoid race conditions with DB sync. - Fix NPE when using segment metadata cache with concurrent locks. - Atomically update segment IDs and pending segments in a `HeapMemoryDatasourceSegmentCache` using methods `syncSegmentIds()` and `syncPendingSegments()` rather than updating one by one. This ensures that the locks are held for a shorter period and the update made to the cache is atomic. Main updated classes ---------------------- - `IndexerMetadataStorageCoordinator` - `OverlordDataSourcesResource` - `HeapMemorySegmentMetadataCache` - `HeapMemoryDatasourceSegmentCache` Cleaner cache sync -------------------- In every sync, the following steps are performed for each datasource: - Retrieve ALL used segment IDs from metadata store - Atomically update segment IDs in cache and determine list of segment IDs which need to be refreshed. - Fetch payloads of segments that need to be refreshed - Atomically update fetched payloads into the cache - Fetch ALL pending segments - Atomically update pending segments into the cache - Clean up empty intervals from datasource caches * GroupBy: Fix offsets on outer queries. (#17837) Prior to this patch, an offset specified on a groupBy that itself has an inner groupBy would lead to an error like "Cannot push down offsets". This happened because of a violated assumption: the processing logic assumes that offsets have been pushed into limits (so limit pushdown optimizations can safely be used). This patch adjusts processing to incorporate offsets into limits during processing of subqueries. Later on, in post-processing, offsets are applied as written. * Enable build cache for web-console (#17831) * run audit fix (#17836) * Do not block task actions on Overlord if segment metadata cache is syncing (#17824) * Do not use segment metadata cache until leader has synced * Read from cache only when synced, but write even if sync is pending * Fix compilation * Fix checkstyle, test * Revert some extra changes * Add 3 modes of cache usage * Move enum to SegmentMetadataCache * Run tests in all 3 cache modes * Fix docs and IT configs * Fix config binding * Remove forbidden api * Fix typos, docs and enum casing * Fix doc * Add json, array, aggregation function tests to quidem (#17842) This PR adds the sql-native portion of the json, array, and aggregation function tests to quidem. It adds a total of 9965 queries, with 6752 positive tests and 3213 negative tests. * Optionally include Content-Disposition header in statement results API response (#17840) Adds support for an optional filename query parameter to the /druid/v2/sql/statements/{queryId}/results API. When provided, the response will include a header Content-Disposition: attachment; filename="{filename}", which will instruct a web browser to save the response as a file rather than displaying it inline. This save-as-attachment behavior could be achieved by adding a "download" attribute to the results link, but this only works for same-origin URLs (as in the Web Console). If the UI origin is different from the Druid API origin, browsers will ignore the attribute and serve the results inline, which is poor UX for files that are potentially very large. For the sake of consistency, all successful responses in SqlStatementResource.doGetResults may include this header, even if there are no results. Release note Improved: The "Get query results" statements API supports an optional filename query parameter. When provided, the response will instruct web browsers to save the results as a file instead of showing them inline (via the Content-Disposition header). * Web console: download follow up (#17845) * set filename * update download button * added markdown support * add test * better download * fix TSV * better download behaviour and tests * always show download all button * Fix flaky unit tests in SegmentBootstrapperTest and KinesisIndexTaskTest (#17841) Changes: - Fix flakiness in SegmentBootstrapperTest - Make TestSegmentCacheManager thread safe by moving from ArrayList to CopyOnWriteArrayList - Modify assertions to disregard list ordering since order of list modifications is not always deterministic - Fix flaky KinesisIndexTask tests. * Web console: responding to user feedback about the explore view and fixing bugs (#17844) * better debounce * better cumpose filter * hook up preview filters * better stack handling * fix some props * refactor stack to facet * fix hover part 1 * line hover part 2 * start adding moduleWhere * info popover * add filter icon * toggle button * module filter bar * update TestSegmentCacheManager * revert some style changes * validate datasource in CachingClusteredClient as well * fix build failure and update style * changes * add inlineds test * add sanity check on segment * inject policy enforcer * add PolicyEnforcer binding in MSQTestBase * add check in SinkQuerySegmentWalker * more tests in realtime server * revert config change in examples * revert config change in integration test config * more tests in msq * another test for unnest in msq * add support for policy from extension * more test * refactor MSQTaskQueryMakerTest to use an instance of MSQTaskQueryMaker * Add test for JoinDataSource * add policyEnforcer to withPolicies, and validate segment after segment mapping * fix binding and test * add policy module * mock planner toolbox * revert some injection * add test for stream appenderator * update PolicyEnforcer to take ReferenceCountingSegment as param * update to QueryLifecycleTest * update to SqlTestFramework * pass enforcer to BroadcastJoinSegmentMapFnProcessor and add test. PolicyEnforcer should also deal with multiple layer wrapped segments/ * ReferenceCountingSegment is not allowed to wrap with a SegmentReference, and PolicyEnforcer now validates all segments, remove test cases for inline/lookup. * moving ReferenceCountingSegment to another pr * Revert "Merge remote-tracking branch 'cecemei/debug' into policy" This reverts commit 25ffb7c, reversing changes made to 1e6632f. --------- Signed-off-by: Emmanuel Ferdman <emmanuelferdman@gmail.com> Co-authored-by: Virushade <70288012+GWphua@users.noreply.github.com> Co-authored-by: Eyal Yurman <eyal.yurman@gmail.com> Co-authored-by: Kashif Faraz <kashif.faraz@gmail.com> Co-authored-by: Frank Chen <frank.chen021@outlook.com> Co-authored-by: Chetan Patidar <122344823+chetanpatidar26@users.noreply.github.com> Co-authored-by: aho135 <ash023@ucsd.edu> Co-authored-by: Adithya Chakilam <35785271+adithyachakilam@users.noreply.github.com> Co-authored-by: Vadim Ogievetsky <vadim@ogievetsky.com> Co-authored-by: Misha <mikhailsviatohorof@gmail.com> Co-authored-by: sviatahorau <mikhail.sviatahorau@deep.bi> Co-authored-by: Benedict Jin <asdf2014@apache.org> Co-authored-by: Clint Wylie <cwylie@apache.org> Co-authored-by: Katya Macedo <38017980+ektravel@users.noreply.github.com> Co-authored-by: Victoria Lim <vtlim@users.noreply.github.com> Co-authored-by: Zoltan Haindrich <kirk@rxd.hu> Co-authored-by: Gian Merlino <gianmerlino@gmail.com> Co-authored-by: Emmanuel Ferdman <emmanuelferdman@gmail.com> Co-authored-by: Om Kenge <88768848+omkenge@users.noreply.github.com> Co-authored-by: Karan Kumar <karankumar1100@gmail.com> Co-authored-by: Lars Francke <lars.francke@stackable.tech> Co-authored-by: Adarsh Sanjeev <adarshsanjeev@gmail.com> Co-authored-by: Akshat Jain <akjn11@gmail.com> Co-authored-by: Andy Tsai <61856143+weishiuntsai@users.noreply.github.com> Co-authored-by: Maytas Monsereenusorn <maytasm@apache.org> Co-authored-by: jtuglu-netflix <jtuglu@netflix.com> Co-authored-by: Lucas Capistrant <capistrant@users.noreply.github.com>

adarshsanjeev added 7 commits March 3, 2025 18:15

Add new dynamic config

7bcb35f

Inject dynamic config

c9a9fd5

Add new API

acb289f

Add new loading pool

386e389

Revert "Inject dynamic config"

48e81dc

This reverts commit c9a9fd5.

Cleanup

270acdf

Clean up

85a1ae8

github-advanced-security AI found potential problems Mar 4, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/http/SegmentListerResource.java Dismissed

Comment thread server/src/main/java/org/apache/druid/server/http/SegmentListerResource.java Dismissed

kfaraz reviewed Mar 4, 2025

View reviewed changes

adarshsanjeev added 3 commits March 4, 2025 12:22

Address review comments

d0c62fd

Address review comments

cf389fe

Revert new API

a1af8c3

adarshsanjeev added 4 commits March 7, 2025 11:39

Address review comments

2ec0dd1

Address review comments

117ae34

Rename config

426def6

Improve coverage

09f679a

kgyrtkirk reviewed Mar 7, 2025

View reviewed changes

adarshsanjeev added 4 commits March 8, 2025 15:42

Add dynamic configuration of batch size

d2b4e93

Add test

6884fc3

Add test

96f89b6

Add test

f81e20f

github-actions Bot added the Area - Documentation label Mar 9, 2025

Fix tests

4a14236

vtlim reviewed Mar 11, 2025

View reviewed changes

adarshsanjeev added 3 commits March 17, 2025 12:21

Fix ITs

a502cef

Merge remote-tracking branch 'origin/master' into turboload-historicals

bdc0334

Update docs

ed7815a

adarshsanjeev added 2 commits March 20, 2025 12:30

Split executors

cf71484

Fix typo

e24c5e0

adarshsanjeev requested a review from vtlim March 20, 2025 07:12

github-advanced-security AI found potential problems Mar 20, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/coordination/SegmentLoadDropHandler.java Fixed

adarshsanjeev requested review from kfaraz and kgyrtkirk March 20, 2025 07:44

kfaraz reviewed Mar 21, 2025

View reviewed changes

Address review comments

844c2f9

github-advanced-security AI found potential problems Mar 21, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/http/SegmentListerResource.java Dismissed

adarshsanjeev added 3 commits March 21, 2025 14:08

Address review comments

dce2f12

Address review comments

42e20d4

Address review comments

fc92af4

kfaraz reviewed Mar 22, 2025

View reviewed changes

Address review comments

d84e31c

github-advanced-security AI found potential problems Mar 24, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/coordinator/loading/HttpLoadQueuePeon.java Fixed

kfaraz reviewed Mar 24, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/coordinator/loading/HttpLoadQueuePeon.java Outdated

adarshsanjeev added 2 commits March 24, 2025 17:15

Add correct threadpool

752c1b7

Add comment

52ac772

kfaraz approved these changes Mar 24, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/coordinator/config/HttpLoadQueuePeonConfig.java

Comment thread server/src/main/java/org/apache/druid/server/http/SegmentLoadingCapabilities.java

kfaraz merged commit 08af98c into apache:master Mar 24, 2025
75 checks passed

abhishekrb19 reviewed Mar 24, 2025

View reviewed changes

Comment thread server/src/main/java/org/apache/druid/server/http/SegmentListerResource.java

adarshsanjeev added the Needs web console change Backend API changes that would benefit from frontend support in the web console label Apr 1, 2025

vogievetsky mentioned this pull request Apr 1, 2025

Web console: add turboLoadingNodes #17860

Merged

adarshsanjeev deleted the turboload-historicals branch April 2, 2025 05:25

kgyrtkirk added this to the 33.0.0 milestone Apr 14, 2025

Conversation

adarshsanjeev commented Mar 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

maytasm commented Mar 4, 2025

Uh oh!

Uh oh!

Uh oh!

kfaraz commented Mar 4, 2025

Uh oh!

kfaraz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

FrankChen021 commented Mar 6, 2025

Uh oh!

Uh oh!

kgyrtkirk Mar 7, 2025

Choose a reason for hiding this comment

Uh oh!

adarshsanjeev Mar 20, 2025

Choose a reason for hiding this comment

Uh oh!

vtlim left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

vtlim Mar 11, 2025

Choose a reason for hiding this comment

Uh oh!

adarshsanjeev Mar 20, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kfaraz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kfaraz left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kfaraz Mar 22, 2025

Choose a reason for hiding this comment

Uh oh!

adarshsanjeev Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

kfaraz Mar 24, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

adarshsanjeev commented Mar 4, 2025 •

edited

Loading

kfaraz left a comment •

edited

Loading

capistrant commented Mar 28, 2025 •

edited

Loading