Support inetd/xinetd through use of System.inheritedChannel()

Sorry, I seem to have assigned the wrong priority, and don't see how to change it. It would be really nice, but it's not a blocker.

I will research this

Is the inherited channel the server socket with the client socket ready to accepted, or is it the accepted client connection?

If it is the later, should jetty try to open the server socket or just deal with the client connection until it is closed and then exit?

cheers

Hi!.. I am just doing a bit of research, and will come back with what I know.

The general gist that I have so far is that Jetty should inherit the socket from inetd and then handle receiving connectings itself in an ongoing basis.. So inetd is acting as a lazy launch platform, but not launching per request.

As I say, I'll come back with more specifics shortly, and hopefully some code samples.

Forgetting my manners.

Thanks for taking this on! ...

Michael Brown,

thanks for bringing it to our attention.

if it is indeed the accepting server socket that is passed, then I believe it will be very simple to support.

cheers

Ok, a long delay and a doctors visit later.

I'm attaching a sample program, with a start script and xinetd config file. It just reports the thread count at 3 seconds intervals, so with multiple telnets you can confirm that a single instance is handling each request. It shows how to inherit the channel and use it. Of course to give it a try yourself you'll have to edit things like the startup path, user and group name.

Frankly it's all pretty simple stuff, but it's nice to show that the API works before anyone does some real work.

To give credit where it's due, this test program was based on the following forum postings:

http://forum.java.sun.com/thread.jspa?threadID=5252233&tstart=45

Err.. Forgot I could write a comment with the file... D'oh.. As above .

Up for grabs

Hi Michael,

Sorry for the long period of inactivity on this ticket. I've taken a look at the code,and I think I know what needs to be done to make Jetty use System.inheritedChannel, but one point: there will still be one instance of the inetd/xinetd service for each instance of Jetty. Jetty would get one instance of the inherited channel, then proceed to listen for incoming connections on the port in the configuration file (in this case 2002)

I'm unsure from the previous comments whether this is what you want/need, and I want to clarify before implementing the changes to make sure I'm missing something.

cheers

Hi Athena,

The key here is that Jetty should listen for connections on the inherited channel, and should not create a new server socket. This is because xinetd will launch Jetty as a result of an incoming connection on that port, and hands the port via inerhitedChannel to jetty, so that it can accept the connection, and any future connections.

Also. Thanks for picking this up .

If I understand you correctly, xinetd hands over control of the port to jetty, so the expected use case is that you will have separate files in /etc/xinetd.d/ like this:

service jetty
{
id = jetty1
port = 2002
...
}

service jetty
{
id = jetty2
port = 2003
...
}

If so, I think I have it working! I'll just need to fix it up a bit.

Attached a patch against Jetty 7, with sample jetty-*.xml configuration file and script for usage.

I'm not sure whether this will be ported to Jetty 6 because Jetty6 still needs to support Java1.4. System.inheritedChannel() is only available from Java 5 onwards

– I'll have to ask.

It should be possible to make the module conditional on the availability of System.inheritedChannel method. Then Jetty 6 will run on 1.4, and this feature would only be allowed on the 1.5 platform.

Although, I do at the same time understand the need to keep new features to new releases.

Michael,

Sorry for the silence. As much as possible, new features added to the experimental branch (jetty7) are added to the stable branch (jetty6). However, with this one, I was very concerned that it would prevent compatibility with Java 1.4, so I ended up sitting on it while trying to figure out how to handle that case. It turns out I need to worry about running with Java 1.4, but not about compiling with Java 1.4, which makes things much simpler.

I'm attaching a revised patch, against both Jetty 6 and Jetty 7, for review. I'd appreciate if you could take a look at the sample xinetd configuration and sample jetty-xinetd.sh script (part of the diff) as well.

Cheers

Athena, good work.... but I have some reservations.

having the ability to call a 1.5 API will prevent these classes loading in 1.4. So I think this has to be a new type of connector rather than modifications to existing ones.

Will the server handle only a single connection (the inherited one), or once started, will it be able to accept more connections? either way, when the number of connections returns to zero, should the server exit?

As the number of connections can be expected to be low, basing a new connector type on socket server should be OK. InheritedSocketConnector it think.

Greg,

Tested, and while I was unable to compile with 1.4, I was able to load the classes (compiled with Java 5). When running with java 1.4, System.inheritedChannel() throws a NoSuchMethodError, which can be caught, but does not prevent the classes from loading entirely. I do like the idea of inheriting off an existing class; feels cleaner. However I am not sure I understand what you mean by the server handling a single connection/closing once the number of connections drop to 0.

If present, the inherited channel will be used as the _acceptChannel within a NIO connector. If not, jetty falls back upon normal ServerSocketChannel creation. Once it is done starting up, the Jetty server instance will act like a normal instance, handling incoming connections from browsers, etc.

Probably the most common use case will be one like Michael described, where a sysad sets up xinetd configuration files for each user ("wait" set to yes will lock their instances of Jetty to the port in the xinetd configuration port). Users can start up their Jetty instances on demand, but it won't be running/taking up resources unless they need it. (On the very first visit, the page will take a long time to load because xinetd is launching the Jetty process, but subsequent page loads will be as normal).

Separated it out into another class, and tweaked the other changes to point to this patch instead. Extended SelectChannelConnector for the new class.

Jesse, can you check/test/commit this for athena.

Thanks

Actually Jesse, I'm assigning this back to athena as I think she has earnt commit rights.
She can commit etc.

Applied the patches. Sorry, Michael, for the delay in getting this committed.