Skip to content

add sorted tablet location partitioner#3562

Open
hlgp wants to merge 3 commits into
integrationfrom
task/sortedLocationPartitioner
Open

add sorted tablet location partitioner#3562
hlgp wants to merge 3 commits into
integrationfrom
task/sortedLocationPartitioner

Conversation

@hlgp
Copy link
Copy Markdown
Collaborator

@hlgp hlgp commented May 19, 2026

No description provided.

SethSmucker added a commit that referenced this pull request May 21, 2026
PR #3560 removed deprecated eventPerDayThreshold and shardsPerDayThreshold
placeholders from the starter source and from docker/config/application-query.yml,
but the released spring-boot-starter-datawave-query-1.0.10.jar still embeds
the old QueryLogicFactory.xml that references those placeholders. With no
fresh 1.0.11 release cut yet, every consumer of the 1.0.10 jar (query,
executor, mapreduce-query, cached-results) fails Spring init at startup
with:

  Caused by: java.lang.IllegalArgumentException: Could not resolve
  placeholder 'datawave.query.logic.logics.BaseEventQuery.eventPerDayThreshold'

This blocks the compose-tests workflow on every recent PR opened against
integration (#3559, #3562, #3563, #3565 all show the same FAILURE).

Bump <version.datawave.starter-query> from 1.0.10 to 1.0.11-SNAPSHOT in the
six consuming poms so the multi-module reactor builds the starter from
current source (which has #3560's removal) and the query/executor docker
images embed the fresh jar.

This is a stop-gap. The proper fix is running microservice-cascade-release.yml
starting from microservices/starters/query to publish a real 1.0.11; once
that lands, these SNAPSHOT pins should be replaced with the released version.

public class SortedTabletLocationPartitioner extends MultiTableRangePartitioner {

private static final Logger log = Logger.getLogger(SortedTabletLocationPartitioner.class);
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would it be worthwhile to use the slf4j loggerfactory initialization for the logger here, or is it basically a wash? If so then you can disregard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants