xiangfu0 commented on code in PR #20023:
URL: https://github.com/apache/pinot/pull/20023#discussion_r4450542756
##########
pinot-spi/src/main/java/org/apache/pinot/spi/utils/CommonConstants.java:
##########
@@ -1770,6 +1781,21 @@ public enum AndRestrictionPushdownMode {
public static final String DEFAULT_SERVER_QUERY_REGEX_CLASS = "JAVA_UTIL";
public static final String CONFIG_OF_ENABLE_QUERY_CANCELLATION =
"pinot.server.enable.query.cancellation";
public static final boolean DEFAULT_ENABLE_QUERY_CANCELLATION = true;
+ /// Allowance for clock skew between a broker and this server when judging
whether a request arrived after the
+ /// broker's deadline for it
([Broker.Request.QueryOptionKey#REQUEST_DEADLINE_MS]). Such a request is
answered
+ /// with a timeout error instead of being executed, but only when it
arrives more than this many milliseconds
+ /// after the deadline. The broker stamps the deadline a few statements
before it starts its own wait for the
+ /// servers, and network or channel-lock delays come after that wait has
started, so with synchronized clocks a
+ /// request is rejected only once the broker has stopped waiting for it
for longer than this allowance; neither a
+ /// slow hop nor a short `timeoutMs` changes that, since the query's
timeout is not part of the comparison. The one
+ /// exposure is a server clock running ahead of the broker's by more than
this allowance: it rejects requests that
+ /// arrive within the excess of their deadline, i.e. every request of a
query whose remaining timeout is shorter
+ /// than the excess. A server clock behind the broker's only makes the
check more lenient. Rejections show up as
+ /// `QuerySchedulingTimeoutError` responses carrying the arrival time and
the deadline, and in the
+ /// `QUERIES_EXPIRED_ON_ARRIVAL` meter. A negative value disables the
check.
+ public static final String CONFIG_OF_REQUEST_DEADLINE_CLOCK_SKEW_MS =
+ "pinot.server.request.deadline.clock.skew.ms";
+ public static final long DEFAULT_REQUEST_DEADLINE_CLOCK_SKEW_MS = 1_000L;
Review Comment:
Raised the default to 10 s, which is far above the skew of hosts that
synchronize their clocks and still well below the minutes-old backlogs this
targets; the config Javadoc now says why, and the new Release notes section in
the description calls it out.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
##########
pinot-core/src/main/java/org/apache/pinot/core/transport/InstanceRequestHandler.java:
##########
@@ -158,11 +175,14 @@ protected void channelRead0(ChannelHandlerContext ctx,
ByteBuf msg) {
queryRequest.getTimerContext().startNewPhaseTimer(ServerQueryPhase.REQUEST_DESERIALIZATION,
queryArrivalTimeMs)
.stopAndRecord();
try {
+ if (rejectIfExpired(queryRequest, ctx, queryArrivalTimeMs)) {
Review Comment:
Moved the check ahead of the compile: it now reads `requestDeadlineMs` from
`instanceRequest.getQuery().getPinotQuery().getQueryOptions()` and the table
from `getTableNameWithType(instanceRequest)`, so an expired request costs only
its deserialization, and a new test shows that an expired request whose query
cannot compile gets the timeout rather than the compile error.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
##########
pinot-core/src/main/java/org/apache/pinot/core/transport/InstanceRequestHandler.java:
##########
@@ -183,6 +203,68 @@ private void sendPingResponse(ChannelHandlerContext ctx,
long requestId) {
}
}
+ /// Answers a request that reached this server after the broker's deadline
for it with a timeout error, without
+ /// executing it, and returns `true`; returns `false` when the request is to
be executed as usual.
+ ///
+ /// The broker sends its deadline as the `requestDeadlineMs` query option,
so a request from an old broker (no
+ /// option) is always executed. The deadline is compared against this
server's clock, which is why it has to be more
+ /// than [Server#CONFIG_OF_REQUEST_DEADLINE_CLOCK_SKEW_MS] in the past
before the request is dropped. Without this
+ /// check a request that spent minutes in the socket buffers of a stalled
connection, and is delivered when the
+ /// connection recovers, is executed with a full timeout budget measured
from its arrival, for a broker that gave up
+ /// on it long ago. The response is still sent: it costs a few bytes and
tells the broker side that the channel is
+ /// alive, even though the broker no longer has a query waiting for it. A
malformed option propagates to the caller,
+ /// which answers with the parse error under the right request id.
+ private boolean rejectIfExpired(ServerQueryRequest queryRequest,
ChannelHandlerContext ctx,
+ long queryArrivalTimeMs) {
+ if (_requestDeadlineClockSkewMs < 0) {
+ return false;
+ }
+ Long requestDeadlineMs =
QueryOptionsUtils.getRequestDeadlineMs(queryRequest.getQueryContext().getQueryOptions());
+ if (requestDeadlineMs == null) {
+ return false;
+ }
+ // Subtract rather than add, so that a huge deadline cannot overflow into
a rejection.
+ long lateByMs = queryArrivalTimeMs - requestDeadlineMs;
+ if (lateByMs <= _requestDeadlineClockSkewMs) {
+ return false;
+ }
+ long requestId = queryRequest.getRequestId();
+ String tableNameWithType = queryRequest.getTableNameWithType();
+ _serverMetrics.addMeteredTableValue(tableNameWithType,
ServerMeter.QUERIES_EXPIRED_ON_ARRIVAL, 1);
+ logExpiredRequest(queryRequest, queryArrivalTimeMs, requestDeadlineMs,
lateByMs);
+ try {
+ DataTable dataTable = DataTableBuilderFactory.getEmptyDataTable();
+ dataTable.getMetadata().put(MetadataKey.REQUEST_ID.getName(),
Long.toString(requestId));
+ dataTable.addException(QueryErrorCode.QUERY_SCHEDULING_TIMEOUT,
Review Comment:
The message now starts with the fixed prefix `Expired on arrival:`
(`InstanceRequestHandler.EXPIRED_ON_ARRIVAL_MESSAGE_PREFIX`), which both tests
assert (the routing one over real Netty), and the config Javadoc plus a new
Release notes section in the description say these responses show up under 240.
_🤖 Addressed by [Claude Code](https://claude.com/claude-code)_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
