-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open Network Connectors before starting contexts. #2053
Conversation
Add option to open network connectors to check port availability prior to starting contexts. Signed-off-by: Greg Wilkins <gregw@webtide.com>
@WalkerWatch this could probably use a small note in the documentation somewhere. This allows a good starting sequence:
|
@joakime @sbordet Should I also add an option (or use this option) to check that the contexts started OK and if not, don't start the connectors. If so, perhaps this option should be renamed (bad name anyway), to something like |
Signed-off-by: Greg Wilkins <gregw@webtide.com>
…en-network-connectors
Signed-off-by: Greg Wilkins <gregw@webtide.com>
@@ -126,6 +126,6 @@ | |||
<Set name="stopTimeout"><Property name="jetty.server.stopTimeout" default="5000"/></Set> | |||
<Set name="dumpAfterStart"><Property name="jetty.server.dumpAfterStart" deprecated="jetty.dump.start" default="false"/></Set> | |||
<Set name="dumpBeforeStop"><Property name="jetty.server.dumpBeforeStop" deprecated="jetty.dump.stop" default="false"/></Set> | |||
<Set name="openNetworkConnectors"><Property name="jetty.server.openNetworkConnectors" default="false"/></Set> | |||
<Set name="verifiedStartSequence"><Property name="jetty.server.verifiedStartSequence" default="false"/></Set> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How many versions of jetty have had the older name?
Do we want to break this kind of backward compat in 9.4.x mid-stream? or wait for jetty 10.x?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
none - the "old" name was new in this pull request.
* @return True if {@link NetworkConnector}s are opened with {@link NetworkConnector#open()} during | ||
* start before handlers are started. | ||
* @return True if the start sequence is verified by checking port availability prior | ||
* to starting contexts and checking contexts prior to starting connectors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This description is awkward to me.
The prior version was more clear.
Are we binding or not?
What about windows and overlapping bind? (where windows allows you to bind to a port already bound by something else without error?) /me shakes fist at IIS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is now doing a bit more, so I put a longer description on the setter, which I hope is clear?
* Set if the start sequence is to be verified by in the following stages: | ||
* <nl> | ||
* <li>{@link NetworkConnector}s are opened with {@link NetworkConnector#open()} to check ports are | ||
* available and to reserve them.</li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you reserving them? or binding them?
This description is awkward (to me)
mex.ifExceptionThrow(); | ||
LOG.info(String.format("Started @%dms",Uptime.getUptime())); | ||
} | ||
finally |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if something above (not in a try/catch of its own) causes an error?
Such as if ShutdownMonitor.register(this) had an exception?
This wouldn't be logged / dumped anywhere, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any other exception would still be thrown as an exception from the original call to start()
and the state would end up as FAILED
. These happen before we open connectors, so that is OK.
However, I think that we should also close any opened connectors if a context fails....
…en-network-connectors
Signed-off-by: Greg Wilkins <gregw@webtide.com>
@sbordet I'm not that keen on the name verifiedStartSequence, but the getter I was thinking about making it build on #1732, but that is actually more complex as it means you have to start the connectors only to pause accepting. Simpler to just open the endpoint to check the port is available (and to reserve it), but not start the connector - as we don't need a started connector to handle existing connections. |
@gregw I'm worried that people assumed |
We've had the ability to call This really just an enhancement of that existing capability so that it is a) possible to do from the module system; b) a lot better on clean up in case this is used from an embedded system where the JVM does not die immediately after failure to start. |
here is a compromise. How about we don't merge this with 9.4, but instead merge it with jetty-10 as the only way we start the server. Ie there will be no mode, it will be just the way we start the server? |
Add option to open network connectors to check port availability prior to starting contexts.
Prompted by question in #2049
Signed-off-by: Greg Wilkins gregw@webtide.com