Skip to content
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

Closed
wants to merge 7 commits into from

Conversation

gregw
Copy link
Contributor

@gregw gregw commented Dec 13, 2017

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

Add option to open network connectors to check port availability prior to starting contexts.

Signed-off-by: Greg Wilkins <gregw@webtide.com>
@gregw
Copy link
Contributor Author

gregw commented Dec 13, 2017

@WalkerWatch this could probably use a small note in the documentation somewhere. This allows a good starting sequence:

  1. Check ports are available and reserve them, but do not accept connections
  2. Start contexts
  3. Start connectors

@gregw
Copy link
Contributor Author

gregw commented Dec 13, 2017

@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 setVerifiedStartSequence(boolean)... in fact I shall do this rename now.... but open to feedback.

Signed-off-by: Greg Wilkins <gregw@webtide.com>
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>
Copy link
Contributor

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?

Copy link
Contributor Author

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.
Copy link
Contributor

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

Copy link
Contributor Author

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>
Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

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....

@sbordet
Copy link
Contributor

sbordet commented Dec 14, 2017

@gregw I don't like the name "verifiedStartSequence" since it does not convey what it really does.
Perhaps "acceptAfterContextStart" ?

Furthermore, I would have expected this feature to build on #1732 (pause accepting) rather than calling open() before start().

@gregw
Copy link
Contributor Author

gregw commented Dec 14, 2017

@sbordet I'm not that keen on the name verifiedStartSequence, but the getter isVerifiedStartSequence returns true iff the start sequence is verified to have worked correctly, so the language works OK. Still open to suggestions for something better, but acceptAfterContextStart is not what it does... there may not even be any contexts... only handlers!

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.

@sbordet
Copy link
Contributor

sbordet commented Dec 14, 2017

@gregw I'm worried that people assumed start() was called before open(), while I understand now the order is reversed ?

@gregw
Copy link
Contributor Author

gregw commented Dec 14, 2017

We've had the ability to call open() before start() for a long time. When users used to hard code XML, it was not uncommon for the open() call to be put into jetty.xml or similar to check the ports were available prior to starting the contexts.

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.

@gregw
Copy link
Contributor Author

gregw commented Dec 27, 2017

@sbordet,

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?

@gregw gregw closed this Jan 8, 2018
@gregw gregw deleted the jetty-9.4.x-open-network-connectors branch January 8, 2018 16:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants