Issue #12047 allow disabling opening connectors before starting

[kelunik]

See #12047.

[joakime]

Looking good.
Can you get a ECA lined up so we can accept this PR?

See https://github.com/jetty/jetty.project/blob/jetty-12.0.x/CONTRIBUTING.md#eclipse-contributor-agreement

[kelunik]

Yes, I'll try to get the ECA sorted.

[joakime]

@kelunik if you can get your ECA sorted today, then this could show up in the next release (12.0.12)
Otherwise it will have to wait till 12.0.13 (or even 12.1.0)

[joakime]

Oops, wrong button. Reopened!

[kelunik]

@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?

[kelunik]

@joakime The ECA is now signed!

[joakime]

@gregw you ok with this change?
The QoSHandlerTest failures here are already fixed in HEAD.

[gregw]

The QoSHandlerTest failures here are already fixed in HEAD.

Actually I just disabled the tests for now....

[gregw]

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.

[joakime]

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.

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

[joakime]

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

[gregw]

@kelunik we've missed the deadline for the current release cycle. Moving this to next months release.
If you can update the names, then I'm inclined to merge it in that cycle.

[kelunik]

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.

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.