I am using latest Jetty v9.4.5, dedicated (NOT embedded). In my Jetty, I got a fine running ROOT.war, so my Jetty is serving one application. So far, so fine.
Right now, I am trying to shutdown Jetty gracefully, as described here. I expect each running request to be finished, but no new request to be accepted.
Right now, I am using start.jar for stopping, as for experimentation. But my target is, to graceful shutdown the Jetty via a SIGTERM-signal to the Jetty-process.
```
java -jar start.jar STOP.PORT=28282 STOP.KEY=verysecret --stop
2017-05-12 16:29:04.260:INFO:oejs.AbstractConnector:ShutdownMonitor: Stopped ServerConnector@7908cfa{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2017-05-12 16:29:04.261:INFO:oejs.session:ShutdownMonitor: Stopped scavenging
2017-05-12 16:29:04.264:INFO:oejshC.ROOT:ShutdownMonitor: Destroying Spring FrameworkServlet 'dispatcherServlet'
2017-05-12 16:29:04.266:INFO:oejshC.ROOT:ShutdownMonitor: Closing Spring root WebApplicationContext
2017-05-12 16:29:04.853:INFO:oejsh.ContextHandler:ShutdownMonitor: Stopped o.e.j.w.WebAppContext@31610302{/,null,UNAVAILABLE}{/ROOT.war}
```
In my experiment, I made my application needing some time for responding.
$ curl http://localhost:8080/
# Returns HTML after a few seconds
Is
Now, when i run my curl, and in parallel afterwards, stop the Jetty, the server responses immediatly, empty.
$ curl http://localhost:8080/
**curl: (52) Empty reply from server**
Should be
In this case, why is my curl not returned a valid answer from Jetty?
Markus,
I believe that graceful stop requires the stats module to be enabled.
regards
On 12 May 2017 at 16:58, Markus Schulte notifications@github.com wrote:
I am using latest Jetty v9.4.5
https://www.eclipse.org/jetty/download.html, dedicated (NOT embedded).
In my Jetty, I got a fine running ROOT.war, so my Jetty is serving one
application. So far, so fine.Right now, I am trying to shutdown Jetty gracefully, as described here
https://github.com/eclipse/jetty.project/issues/1415. I expect each
running request to be finished, but no new request to be accepted.Right now, I am using start.jar for stopping, as for experimentation. But
my target is, to graceful shutdown the Jetty via a SIGTERM-signal to the
Jetty-process.java -jar start.jar STOP.PORT=28282 STOP.KEY=verysecret --stop
Jetty log
2017-05-12 16:29:04.260:INFO:oejs.AbstractConnector:ShutdownMonitor: Stopped ServerConnector@7908cfa{HTTP/1.1,[http/1.1]}{0.0.0.0:8080}
2017-05-12 16:29:04.261:INFO:oejs.session:ShutdownMonitor: Stopped scavenging
2017-05-12 16:29:04.264:INFO:oejshC.ROOT:ShutdownMonitor: Destroying Spring FrameworkServlet 'dispatcherServlet'
2017-05-12 16:29:04.266:INFO:oejshC.ROOT:ShutdownMonitor: Closing Spring root WebApplicationContext
2017-05-12 16:29:04.853:INFO:oejsh.ContextHandler:ShutdownMonitor: Stopped o.e.j.w.WebAppContext@31610302{/,null,UNAVAILABLE}{/ROOT.war}In my experiment, I made my application needing some time for responding.
$ curl http://localhost:8080/
Returns HTML after a few seconds
Is
Now, when i run my curl, and in parallel afterwards, stop the Jetty, the
server responses immediatly, empty.$ curl http://localhost:8080/
curl: (52) Empty reply from serverShould be
In this case, why is my curl not returned a valid answer from Jetty?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/jetty.project/issues/1549, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEUrUBZxWELtNncFWxZKtvqPMz_fpFRks5r5HN4gaJpZM4NZZis
.
--
Greg Wilkins gregw@webtide.com CTO http://webtide.com
Hi @gregw
you are right. After
jetty-distribution-9.4.5.v20170502 $ java -jar start.jar --add-to-start=stats
the Jetty behaves as expected (with SIGTERM, too). Thank you!
@WalkerWatch even tho this issue is closed, it would be a good idea to check the documentation, as it seems a little non-intuitive that one needs the stats module enabled to make graceful stop work, so we should make sure we have that documented.
Why do we need the stats module?
The org.eclipse.jetty.util.component.Graceful interface is the mechanism we use.
And its declared on:
org.eclipse.jetty.server.Connectororg.eclipse.jetty.server.handler.ContextHandlerorg.eclipse.jetty.server.handler.StatisticsHandlerWhy should StatisticsHandler be the magic key?
Wouldn't the WebAppContext > ServletContextHandler > ContextHandler hierarchy satisfy the same requirement?
The stats handler is required because it is the only handler that keeps
track of the number of outstanding requests. So it is the stats handler
that delays the stop until requests have gone to zero.
If graceful stop didn't rely on the stats handler, then we'd need to
duplicate the logic of counting outstanding requests.
On 12 May 2017 at 17:46, Joakim Erdfelt notifications@github.com wrote:
Why do we need the stats module?
The org.eclipse.jetty.util.component.Graceful interface is the mechanism
we use.And its declared on:
- org.eclipse.jetty.server.Connector
- org.eclipse.jetty.server.handler.ContextHandler
- org.eclipse.jetty.server.handler.StatisticsHandler
Why should StatisticsHandler be the magic key?
Wouldn't the WebAppContext > ServletContextHandler > ContextHandler
hierarchy satisfy the same requirement?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/eclipse/jetty.project/issues/1549#issuecomment-301113124,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEUrWQmndHuXxTyzA-M71ZaKwy3nghEks5r5H7WgaJpZM4NZZis
.
--
Greg Wilkins gregw@webtide.com CTO http://webtide.com
@janbartel I was thinking the same thing.
Hi all,
Is StatisticsHandler production ready? It's the overhead added small enough to be ignored?
@trance1st please don't hijack 2 years old issues.
If you have a question, open a new issue and label it with the Question label.
Most helpful comment
@WalkerWatch even tho this issue is closed, it would be a good idea to check the documentation, as it seems a little non-intuitive that one needs the stats module enabled to make graceful stop work, so we should make sure we have that documented.