Issue #12047 allow disabling opening connectors before starting #12049
Conversation
|
Looking good. |
|
Yes, I'll try to get the ECA sorted. |
|
@kelunik if you can get your ECA sorted today, then this could show up in the next release (12.0.12) |
|
Oops, wrong button. Reopened! |
|
@joakime Unless I redeclare this as a personal contribution, I can't make this happen today. But I'm also not in a hurry as the workaround works fine for me, so shipping in a later release is OK. Anything I can do for the failing jenkins steps? |
|
@joakime The ECA is now signed! |
|
@gregw you ok with this change? |
Actually I just disabled the tests for now.... |
There was a problem hiding this comment.
I'm a bit dismayed that webapplications can take soooo long to start that this is an issue.
Perhaps trying the quickstart mechanism to prescan all your webapps would be a better approach? It should only take a few 100 micro seconds to start such a server.
But if this is really needed, I have a quibble about the name.
jetty-core/jetty-server/src/main/java/org/eclipse/jetty/server/Server.java
Outdated
Show resolved
Hide resolved
For a webapp that depends only on Servlet behaviors, yes, this is very possible. But if you have a webapp that does scanning from multiple 3rd party libraries (eg: certain spring configurations, specific hibernate configurations, some jersey configs, etc) then each of those adds to the time to startup because each of those will scan the entire webapp bytecode for things like interfaces, annotations, etc. Even though the modern era of webapp development can be quite complicated, don't worry too much about the details. Just try the Jetty QuickStart mechanism (for your ee# environment) and see how it helps. https://jetty.org/docs/jetty/12/operations-guide/quickstart/index.html |
|
Know that you can also tweak what jars are actually scanned on the Container classloader and the Webapp classloader with configuration. This is an alternative to using quickstart. See https://jetty.org/docs/jetty/12/operations-guide/annotations/index.html#scanning |
|
@kelunik we've missed the deadline for the current release cycle. Moving this to next months release. |
kelunik
force-pushed
the
late-socket-bind
branch
from
27859ed
to
dc04e3e
Compare
kelunik
force-pushed
the
late-socket-bind
branch
from
dc04e3e
to
b2a0e81
Compare
Scanning isn't what's causing our server to need time to start. It's the Spring context that loads lots of data into memory on start. But even a few seconds to start would cause additional latency in our load balancer setup, because once the socket is open, the load balancer tries to send requests (due to passive healthchecks). I've adjusted the naming and rebased onto the latest 12.x branch, so hopefully everything is fine now. |
See #12047.