Make the following changes to improve the thread-safety of
QueryUncaughtExceptionHandler, and add test coverage.
- Generate a sequence for each call to uncaughtException() to help
ensure the first call with a non-null Throwable wins the race,
regardless of which thread's CAS operation completes first.
- In uncaughtException(), atomically update the sequence number, thread,
and throwable at the same time.
- Use an efficient, thread-safe collection for storing and retrieving
messages.
---------
Co-authored-by: Moriarty <[email protected]>
## Summary
- `QueryMetric`'s `createDate` is stamped from wall-clock time
(truncated to the second) and is part of `equals()`/`hashCode()`. A
prior fix (#3658) worked around a resulting flake in `testPredict()` by
relaxing a Mockito `eq(metric)` matcher to `any(BaseQueryMetric.class)`,
but that gave up on verifying the actual metric passed to the predictor.
- This restores strict matching without the race: `QueryMetricFactory`
is mocked directly, and `ReflectionTestUtils.setField(m, "createDate",
...)` pins the same `createDate` on both the metric the bean builds
internally and the metric built for comparison in the test, so the two
sides can no longer straddle a second boundary.
- No production code changes — confined to the test file.
## Test plan
- [x] `mvn -pl web-services/query -Dtest=QueryExecutorBeanTest test` —
9/9 pass
- [x] `testPredict` re-run 5x in a row to confirm no flakiness
Co-authored-by: Claude Sonnet 5 <[email protected]>
## Summary
- Replaces JUnit4/PowerMock/EasyMock with JUnit5/Mockito in
`QueryExecutorBeanTest`
- Removes `@RunWith(PowerMockRunner.class)`, `@PrepareForTest`, and
`@PowerMockIgnore` in favour of `@ExtendWith(MockitoExtension.class)`
with `LENIENT` strictness
- Converts all `createStrictMock`/`createMock` → `mock()`,
`expect/andReturn/replayAll/verifyAll` → `when/thenReturn`, and
`IAnswer` → `Answer` lambdas
- Replaces `Whitebox.setInternalState`/`getInternalState` with
`ReflectionTestUtils.setField`/`getField`
- Removes `suppress(constructor(DefaultQueryParameters.class))` — safe
because production code calls `qp.clear()`, not `new
DefaultQueryParameters()`
- Uses static imports for all JUnit assertions
## Test plan
- [ ] `mvn -pl web-services/query test -Dtest=QueryExecutorBeanTest` —
all 9 tests pass
- [ ] `mvn -pl web-services/query clean test` — full module build passes
(30 test classes, 0 failures)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Sonnet 4.6 <[email protected]>
## Summary
- Replaces all 120 uses of `datawave.util.TableName` (deprecated since
7.40.0, `forRemoval=true`) with the new
`datawave.table.constants.TableName` class in `core/tables`
- Adds an explicit `datawave-core-tables` dependency to
`core/query/pom.xml` — the only affected module that didn't already have
it transitively
## Test plan
- [x] Formatting build passes (`mvn clean install -DskipTests
-DskipITs`)
- [x] Full test suite passes on CI
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Sonnet 4.6 <[email protected]>
Replace PowerMock/EasyMock with Mockito (MockedStatic for
FindAnnotation, ReflectionTestUtils for field access) and upgrade JUnit4
to JUnit5.
---------
Co-authored-by: Claude Sonnet 4.6 <[email protected]>
Co-authored-by: palindrome <[email protected]>
The ActiveQueryTracker creates a new zookeeper client everytime we
create a new QueryHeartbeat via ActiveQueryTracker.trackQuery(). This
client does not get closed and results in ever-increasing Curator
Framework threads that eventually affect server performance.
Make changes to effect the following:
- Reuse the same ActiveQueryTracker zookeeper client when creating new
heartbeats.
- Modify the ActiveQueryTracker to ensure this client is not
periodically cleaned up, and is instead kept alive for the lifetime of
the ActiveQueryTracker instance.
- Update documentation.
Co-authored-by: hgklohr <[email protected]>
update accumulo-utils to use a POJO for storing markings and then
updated the rest of the codebase that referenced it.
replaced some of the ColumnVisibility usage with AccessExpression to
improve performance.
---------
Co-authored-by: Joe Alphonso <[email protected]>
Ensure the QueryLimiter is properly injected into the CachedResultsBean
and the QueryExpirationBean.
Fixes#3536
---------
Co-authored-by: foster33 <[email protected]>
Co-authored-by: Drew Farris <[email protected]>
**IndexExpansionQueryTest.java**
- Due to the random nature of these tests the
DatawaveFatalQueryException is not always thrown
**QueryLimiterConcurrencyTest.java**
- query creation time allowance is too short when running tests
concurrently (100L -> 250L)
**ExtendedRunningQueryTest.java**
- resolves race condition by explicitly setting the list of boolean
return values for the hasNext mock
Co-authored-by: Joe Alphonso <[email protected]>
## Configuration
Add the ability to enforce concurrent query limits across a group of
webservers. Zookeeper is used to track active queries and the following
data:
- The query ID
- The user who submitted the query
- The system the query was submitted on
- The query logic the query originated from
Query limit enforcement is done through the `QueryLimiter` class. Given
a user, system, and query logic, it can determine if any of the
following limits have been exceeded:
- The max allowed concurrent queries for the user.
- The max allowed concurrent queries of the query logic for the user.
- The max allowed concurrent queries for the system.
- The max allowed concurrent queries of the query logic for the system.
Limits may be defined and customized on a per-user and per-system basis.
They may also be defined for groups of query logics. The classes
`UserLimitProvider`, `SystemLimitProvider`, and
`QueryLogicGroupLimitProvider` are respectively responsible for
identifying the best limits to enforce for a user, system, and query
logic. They will be initialized in the `QueryLimiter` after providing a
`QueryLimitConfiguration` instance. The following can be configured:
On a system-wide basis:
- The default concurrent user query limit. This applies to the total
number of queries a user may run across all systems. May be overridden
per user.
- The default concurrent system query limit. Primarily to avoid a system
getting overloaded. May be overridden per system.
On a per-system basis:
- The system name/ids the configuration targets. Regex matching is
supported. Pattern uniqueness is enforced.
- The concurrent system query limit. Overrides the system-wide value.
- Whether queries submitted to the system count towards a user's
concurrent query total. This is always true unless specified otherwise.
- The concurrent system query limit for different query logic groups.
Regex matching against group names is supported. Pattern uniqueness is
enforced.
On a per-user basis:
- The user DN.
- The user's concurrent query limit. Overrides the system-wide
configuration.
- The user's concurrent query limit for different query logic groups.
Regex matching against group names is supported.
On a per-query-logic-group basis:
- The group name.
- The query logics included in the group. Regex matching is supported.
Pattern uniqueness is enforced.
- The default concurrent user query limit. This applies to the total
concurrent queries a user may run that originate from a query logic in
the group across all systems.
Given the possibilities for exact matches, partial regex matches, and
wildcard regex matches, the determination of the best limit to use for
any particular system, query logic, or query logic group is done by
sorting matches into the following 'matching buckets' (in best-match
priority):
1. Exact match: We attempt to find an exact match first and use the
associated limit.
2. Partial regex (non-wildcard-only): If we cannot find an exact match,
then we attempt to find all partial matches, and see if any of their
limits are met.
3. Wildcard-only regex: In the case of no exact or partial matches, we
use the wildcard match with the lowest limit.
## Implementation
Checking limits and marking as active/inactive is done through the
`QueryLimiter` class. The three main methods to know are:
- `QueryLimiter.checkForLimits()`
- `QueryLimiter.countQueryTowardsLimits()`
- `QueryLimiter.stopCountingQueryTowardsLimits()`
When a query is marked as active via
`QueryLimiter.countQueryTowardsLimits()`, it will delegate to the
ActiveQueryTracker, which will in turn create nodes in Zookeeper under
the `ActiveQueries` namespace. When `ActiveQueryTracker.trackQuery()` is
called, the following nodes are created:
```
# Container nodes
/users/<userDn>/<queryLogic> # Only for queries on systems that count towards user limit
/systems/<system>/<queryLogic>
/distinctQueryLogics/<queryLogic> [Only created if it does not exist.]
# Ephemeral nodes. These will auto-delete themselves if their associated Zookeeper connection ever goes down.
/users/<userDn>/<queryLogic>/<queryId> # Only for queries on systems that count towards user limit
/systems/<system>/<queryLogic>/<queryId>
```
`ActiveQueryTracker.trackQuery()` will return a `QueryHeartbeat` that
contain a list of `PersistentNode` (provided by the Apache Curator
library) wrappers around the ephemeral nodes listed above. The
`QueryHeartbeat` will maintain the connection to Zookeeper and attempt
to keep the ephemeral nodes present in Zookeeper until
`QueryHeartbeat.stop()` is called. If `QueryHeartbeat.stop()` is called,
or the webserver crashes, the ephemeral nodes will automatically be
deleted by Zookeeper.
The following error codes have been added:
```
412-20 - Concurrent query limit exceeded
500-164 - Error checking concurrent query limits
```
Closes#3100
---------
Co-authored-by: Bill Oley <[email protected]>
Co-authored-by: foster33 <[email protected]>
Co-authored-by: Ivan Bella <[email protected]>
Remove Powermock from CreatedQueryLogicCacheBeanTest
Replaces System.currentTimeMillis() call with Clock.millis(), allowing
for easier mocking in unit tests.
Refactored CreatedQueryLogicCacheBeanTest such that asserts are more
behavior driven and declarative.
Updated the QueryExecutorBean amongst other clases to set the
ExecutorService on the RunningQuery as the ManagedExecutorService. The
ManagerExecutorService will handle passing the roles onto the threads
which allows query logics to make calls to other EJBs as needed.
Remove some instances of PowerMock from web-services/query module
Completely refactored ConfiguredQueryLogicFactoryBeanTest to rely on
Spring as much as possible
Deleted redundant QueryLogicFactoryBeanTest
