LuciferYang opened a new issue, #13912:
URL: https://github.com/apache/gravitino/issues/13912
### Version
main branch
### Describe what's wrong
`JettyServer` sets `setStopAtShutdown(true)` and a `stopTimeout`
(`gravitino.*.stopTimeout`, 30 s by default, documented as the time to
"gracefully shutdown the Jetty webserver"), but it has no `StatisticsHandler`.
In Jetty 9.4, `Server.doStop` only waits for graceful handlers, so the
connections of in-flight requests are closed as soon as the server stops. The
request keeps running on the server and its result is lost: the client sees a
dropped connection for an operation that may have succeeded. Jetty still waits
for the busy worker thread before the JVM exits, so closing the connection
early does not make the shutdown faster.
This applies to the Gravitino server, the Iceberg REST server and the Lance
REST server, which all use `JettyServer`. `bin/<server>.sh stop` sends SIGTERM,
so a local stop hits it today; containers hit it once SIGTERM reaches the JVM
(#13868).
### Error message and/or stacktrace
The client gets an empty reply, for example `curl: (52) Empty reply from
server`.
### How to reproduce
1. Run the Iceberg REST server with a REST backend whose create-namespace
call takes 8 seconds.
2. `POST /iceberg/v1/namespaces` with `{"namespace":["ns1"]}`, and stop the
server 2 seconds later with `bin/gravitino-iceberg-rest-server.sh stop`.
3. The client gets an empty reply right away. The backend still creates
`ns1` 6 seconds later, and retrying the request returns 409
`AlreadyExistsException`.
### Additional context
_No response_
--
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]
