Rename evaluationTimeout to timeoutMs

CHANGELOG.asciidoc

@@ -39,7 +39,7 @@ image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 * Removed `Transaction.open()` in favor of `begin()`, which is now the single transaction-start primitive across embedded and remote contexts.
 * Changed `begin()` and `close()` to be idempotent and calling it when a transaction is already in that state no longer throws.
 * Added `maxTransactionLifetime` setting to Gremlin Server, an absolute cap on the total age of an HTTP transaction that interrupts a running operation and rolls the transaction back when it fires (default 600000ms, set to `0` to disable).
-* Changed the Gremlin Server HTTP transaction idle timer to suspend while an operation is running (so a long-running operation is bounded by `evaluationTimeout` rather than the idle timeout) and to honor `0` as "disable idle reclamation"; the `idleTransactionTimeout` default is now 60000ms.
+* Changed the Gremlin Server HTTP transaction idle timer to suspend while an operation is running (so a long-running operation is bounded by `timeoutMs` rather than the idle timeout) and to honor `0` as "disable idle reclamation"; the `idleTransactionTimeout` default is now 60000ms.
 * Added configurable CORS `allowedOrigins` setting to Gremlin Server; warns when wildcard origin is used alongside authentication.
 * Fixed `ByteBuf` leak in `GraphBinaryMessageSerializerV4` when serialization throws an `IOException`.
 * Changed `Tree` to no longer extend `HashMap`; it is now a final class with a tree-shaped API (`childAt`, `hasChild`, `contains`, `findSubtree`, `getOrCreateChild`, `getNodesAtDepth`, `getLeafNodes`, `nodeCount`) and is no longer a `Map`.
@@ -82,6 +82,7 @@ image::https://raw.githubusercontent.com/apache/tinkerpop/master/docs/static/ima
 * Deprecated Groovy-based `LifeCycleHook` and `TraversalSource` creation via init scripts in favor of YAML configuration.
 * Updated all default Gremlin Server configs to remove Groovy dependency from initialization.
 * Added script engine allowlist to Gremlin Server - the `scriptEngines` YAML configuration now restricts which engines can serve requests; `gremlin-lang` is always available.
+* Modified the request timeout to a single name `timeoutMs` across the server and GLVs.
 * Modified request parameters from `Map<String, Object>` to gremlin-lang compatible `String`.
 * Modified HTTP API to expect gremlin-lang strings for parameters and update all GLVs to send requests in new format.
 * Added string parameter parsing to `GremlinServer` to prevent traversal injection and excessive nesting depths.

docker/gremlin-server/gremlin-server-integration-krb5.yaml

@@ -17,7 +17,7 @@
 
 host: 0.0.0.0
 port: 45942
-evaluationTimeout: 30000
+timeoutMs: 30000
 graphs: {
   graph: {
     configuration: conf/tinkergraph-empty.properties,

docker/gremlin-server/gremlin-server-integration-secure.yaml

@@ -17,7 +17,7 @@
 
 host: 0.0.0.0
 port: 45941
-evaluationTimeout: 30000
+timeoutMs: 30000
 graphs: {
   graph: {
     configuration: conf/tinkergraph-empty.properties,

docker/gremlin-server/gremlin-server-integration.yaml

@@ -17,7 +17,7 @@
 
 host: 0.0.0.0
 port: 45940
-evaluationTimeout: 30000
+timeoutMs: 30000
 channelizer: org.apache.tinkerpop.gremlin.server.channel.HttpChannelizer
 graphs: {
   graph: {

docs/src/dev/provider/index.asciidoc

@@ -1430,8 +1430,8 @@ rejects it with HTTP 400. This prevents cross-graph operations within a single t
 
 ==== Transaction Timeout and Idle Reclamation
 
-A transaction can be bounded at three independent scopes, each disabled with `0`. The `evaluationTimeout` bounds a
-single operation. The `idleTransactionTimeout` (default 60000ms) bounds the idle gaps between operations: how long a
+A transaction can be bounded at three independent scopes, each disabled with `0`. The `timeoutMs` bounds a single
+operation. The `idleTransactionTimeout` (default 60000ms) bounds the idle gaps between operations: how long a
 transaction may remain idle, with no operation running or queued, before it is rolled back and removed; once it is
 removed, a subsequent request with that transaction ID receives a 404. The `maxTransactionLifetime` (default 600000ms)
 bounds the total age of the transaction regardless of activity, and so may end a transaction while an operation is still

docs/src/reference/gremlin-applications.asciidoc

@@ -930,7 +930,7 @@ The following table describes the various YAML configuration options that Gremli
 |gremlinPool |The number of "Gremlin" threads available to execute actual scripts in a `ScriptEngine`. This pool represents the workers available to handle blocking operations in Gremlin Server. When set to `0`, Gremlin Server will use the value provided by `Runtime.availableProcessors()`. |0
 |host |The name of the host to bind the server to. |localhost
 |idleConnectionTimeout |Time in milliseconds that the server will allow a channel to not receive requests from a client before it automatically closes. If enabled, the value provided should typically exceed the amount of time given to `keepAliveInterval`. Note that while this value is to be provided as milliseconds it will resolve to second precision. Set this value to `0` to disable this feature. |0
-|idleTransactionTimeout |Time in milliseconds that a transaction can remain idle (no operation running or queued) before the server forcibly rolls it back and removes it. The idle timer is suspended while an operation is running, so a long-running operation does not trip it (its duration is instead bounded by `evaluationTimeout`); the timer is armed only once the transaction returns to idle. Set to `0` to disable idle reclamation. |60000
+|idleTransactionTimeout |Time in milliseconds that a transaction can remain idle (no operation running or queued) before the server forcibly rolls it back and removes it. The idle timer is suspended while an operation is running, so a long-running operation does not trip it (its duration is instead bounded by `timeoutMs`); the timer is armed only once the transaction returns to idle. Set to `0` to disable idle reclamation. |60000
 |keepAliveInterval |Time in milliseconds that the server will allow a channel to not send responses to a client before it sends a "ping" to see if it is still present. If it is present, the client should respond with a "pong" which will thus reset the `idleConnectionTimeout` and keep the channel open. If enabled, this number should be smaller than the value provided to the `idleConnectionTimeout`. Note that while this value is to be provided as milliseconds it will resolve to second precision. Set this value to `0` to disable this feature. |0
 |maxAccumulationBufferComponents |Maximum number of request components that can be aggregated for a message. |1024
 |maxChunkSize |The maximum length of the content or each chunk.  If the content length exceeds this value, the transfer encoding of the decoded request will be converted to 'chunked' and the content will be split into multiple `HttpContent` objects.  If the transfer encoding of the HTTP request is 'chunked' already, each chunk will be split into smaller chunks if the length of the chunk exceeds this value. |8192
@@ -969,7 +969,6 @@ The following table describes the various YAML configuration options that Gremli
 |lifecycleHooks |A `List` of Java-based `LifeCycleHook` implementations to instantiate and execute during server startup and shutdown.  See <<server-lifecycle-hooks>>. |_none_
 |lifecycleHooks[X].className |The fully qualified class name of the `LifeCycleHook` implementation. |_none_
 |lifecycleHooks[X].config |A `Map` of configuration passed to the hook's `init(Map)` method. |_none_
-|evaluationTimeout |The amount of time in milliseconds before a request evaluation and iteration of result times out. This feature can be turned off by setting the value to `0`. |30000
 |serializers |A `List` of `Map` settings, where each `Map` represents a `MessageSerializer` implementation to use along with its configuration. If this value is not set, then Gremlin Server will configure with GraphSON and GraphBinary but will not register any `ioRegistries` for configured graphs. |_empty_
 |serializers[X].className |The full class name of the `MessageSerializer` implementation. |_none_
 |serializers[X].config |A `Map` containing `MessageSerializer` specific configurations. |_none_
@@ -985,6 +984,7 @@ The following table describes the various YAML configuration options that Gremli
 |strictTransactionManagement |Set to `true` to require `aliases` to be submitted on every requests, where the `aliases` become the scope of transaction management. |false
 |threadPoolBoss |The number of threads available to Gremlin Server for accepting connections. Should always be set to `1`. |1
 |threadPoolWorker |The number of threads available to Gremlin Server for processing non-blocking reads and writes. |1
+|timeoutMs |The maximum amount of time in milliseconds that a request is allowed to execute on the server before it times out. This is the server-wide default and may be overridden on a per-request basis with the `timeoutMs` request argument. This feature can be turned off by setting the value to `0`. |30000
 |useEpollEventLoop |Try to use epoll event loops (works only on Linux os) instead of netty NIO. |false
 |writeBufferHighWaterMark | If the number of bytes in the network send buffer exceeds this value then the channel is no longer writeable, accepting no additional writes until buffer is drained and the `writeBufferLowWaterMark` is met. |65536
 |writeBufferLowWaterMark | Once the number of bytes queued in the network send buffer exceeds the `writeBufferHighWaterMark`, the channel will not become writeable again until the buffer is drained and it drops below this value. |32768
@@ -1769,7 +1769,7 @@ continuously:
 client = Cluster.build("localhost").port(8182).create().connect()
 ==>org.apache.tinkerpop.gremlin.driver.Client$ClusteredClient@42ff9a77
 client.submit("while(true) { }")
-org.apache.tinkerpop.gremlin.driver.exception.ResponseException: A timeout occurred during traversal evaluation of [RequestMessage{, fields={bindings={}, language=gremlin-groovy, batchSize=64}, gremlin=while(true) { }}] - consider increasing the limit given to evaluationTimeout
+org.apache.tinkerpop.gremlin.driver.exception.ResponseException: A timeout occurred during traversal evaluation of [RequestMessage{, fields={bindings={}, language=gremlin-groovy, batchSize=64}, gremlin=while(true) { }}] - consider increasing the limit given to timeoutMs (the maximum time in milliseconds a request may execute on the server)
 
 The `GroovyCompilerGremlinPlugin` has a number of configuration options:
 
@@ -1923,11 +1923,11 @@ generally means being measured in the low hundreds of milliseconds and "slow" me
 * Requests that are "slow" can really hurt Gremlin Server if they are not properly accounted for. Since these requests
 block a thread until the job is complete or successfully interrupted, lots of long-run requests will eventually consume
 the `gremlinPool` preventing other requests from getting processed from the queue.
-** To limit the impact of this problem, consider properly setting the `evaluationTimeout` to something "sane".
+** To limit the impact of this problem, consider properly setting the `timeoutMs` to something "sane".
 In other words, test the traversals being sent to Gremlin Server and determine the maximum time they take to evaluate
 and iterate over results, then set the timeout value accordingly. Also, consider setting a shorter global timeout for
 requests and then use longer per-request timeouts for those specific ones that might execute at a longer rate.
-** Note that `evaluationTimeout` can only attempt to interrupt the evaluation on timeout.  It allows Gremlin
+** Note that `timeoutMs` can only attempt to interrupt the evaluation on timeout.  It allows Gremlin
 Server to "ignore" the result of that evaluation, which means the thread in the `gremlinPool` that did the evaluation
 may still be consumed after the timeout if interruption does not succeed on the thread.
 * When using transactions, the server dedicates resources to maintain transaction state for each open transaction. For
@@ -2266,13 +2266,13 @@ server forcibly rolls it back. The idle timer is suspended while an operation is
 does not trip it; it is armed only once the transaction returns to idle. Set it to `0` to disable idle reclamation. The
 `maxTransactionLifetime` (default 600000ms) is an absolute cap on the total age of a transaction regardless of
 activity. Unlike `idleTransactionTimeout`, it fires even while an operation is running, interrupting it and rolling the
-transaction back. It bounds transaction lifetime and concurrency-slot occupancy absolutely; like `evaluationTimeout`,
-its ability to free the underlying worker thread depends on the operation reaching an interruptible point. Set it to
+transaction back. It bounds transaction lifetime and concurrency-slot occupancy absolutely; like `timeoutMs`, its
+ability to free the underlying worker thread depends on the operation reaching an interruptible point. Set it to
 `0` to disable the cap. Finally, `maxConcurrentTransactions` (default 1000) caps the number of open transactions
 allowed; when the limit is reached, new begin requests are rejected with HTTP 503.
 
-These compose with the per-operation `evaluationTimeout` (and its per-request `timeoutMs` override) to bound a
-transaction at three independent scopes: a single operation (`evaluationTimeout`), the gaps between operations
+These compose with the per-operation `timeoutMs` (configurable server-wide and overridable per request) to bound a
+transaction at three independent scopes: a single operation (`timeoutMs`), the gaps between operations
 (`idleTransactionTimeout`), and the transaction as a whole (`maxTransactionLifetime`). The defaults keep a transaction
 bounded out of the box; disabling all of them is a deliberate operator choice, and a per-request `timeoutMs` is always
 honored as sent.