Jetty interprets JETTY_ARGS as file name

jetty

I'm running Jetty (version "null 6.1.22") on Ubuntu 10.04. It's running fine until I need JSP support. According to several blog posts I need to set the JETTY_ARGS to OPTIONS=Server,jsp. However, if I put this into /etc/default/jetty:

JETTY_ARGS=OPTIONS=Server,jsp

and restart Jetty via /etc/init.d/jetty stop && /etc/init.d/jetty start, it reports success, but does not accept connections. I notices that it logs something to /usr/share/jetty/logs/out.log:

2012-09-11 11:19:05.110:WARN::EXCEPTION 
java.io.FileNotFoundException: /var/cache/jetty/tmp/OPTIONS=Server,jsp (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:137)
at java.io.FileInputStream.<init>(FileInputStream.java:96)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:87)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:178)
at com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:630)
at com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:189)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:776)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:741)
at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123)
at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208)
at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525)
at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:188)
at org.mortbay.xml.XmlParser.parse(XmlParser.java:204)
at org.mortbay.xml.XmlConfiguration.<init>(XmlConfiguration.java:109)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:969)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.jetty.start.daemon.Bootstrap.start(Bootstrap.java:30)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.apache.commons.daemon.support.DaemonLoader.start(DaemonLoader.java:177)

That is, whatever I put into JETTY_ARGS, it inteprets is as a filename inside /var/cache/jetty/tmp/ and tries to parse that file as XML (or does it parse some other XML and tries to read that file as a DTD? I'm not sure.). This doesn't seem to make any sense to me, especially since that directory is entirely empty. I've verified this with several other Strings, not only OPTIONS=Server,jsp.

Update:

According to this page in the Eclipsepedia, I should be able to start Jetty by invking:

java -jar start.jar OPTIONS=Server,jsp

This creates exactly the same exception as above. Just invoking this works, but again without JSP support:

java -jar start.jar

Best Answer

The part in your output that says org.mortbay.start.Main.start means you are running a version of Jetty (6.x or earlier).

Any documentation you found at eclipse.org/jetty/documentation/ or wiki.eclipse.org/Jetty is inappropriate for that version of Jetty.

Use the archived documentation at docs.codehaus.org/display/JETTY/Jetty+Documentation instead.

The fact that you have a /etc/init.d/jetty means you are likely running jetty built by one of the linux distributions. There are unfortunately many bugs to be found in the startup and initialization process in the various linux distribution created jetty bundles, especially with the created and bundled /etc/init.d/jetty. The various bug tracking systems at debian and redhat are the place to file bugs against these files.

The command line you used:

$ java -jar start.jar OPTIONS=Server,jsp

is for direct, stand alone, execution, and is only designed to work with the standard jetty distribution from dist.codehaus.org, the maven.org repo, or download.eclipse.org.

Note that the jetty-distribution comes with a bin/jetty.sh, which has had many fixes to be friendly for various sysvinit systems.

However, that being said, there have many bug fixes and improvements with the startup processes in Jetty since moving to eclipse (Jetty 7+), including the introduction of a start.ini, similar to how eclipse itself can be configured for startup, which eliminated many of these kinds of issues you are experiencing.

Related Solutions

Apache and jetty

All the comet solutions rely on holding the connection between the webserver open as long as possible, either by the client making a POST request and then delaying sending the data, or the server sending a GET response, again delaying the data.

Both of those have similar problems for the origin, namely consuming a socket and memory per connection, and possibly a thread, unless you are using something like Jetty continuations.

By placing a reverse proxy like Apache in front of Jetty, like apache each open connection between Jetty and the client will also consume a worker. Depending on which apache worker model you choose (for example mod_prefork or mod_worker_mpm) there will be limitations on the maximum number of connections your apache server can support. That is around a couple of hundred for mod_prefork and is generally limited by the amount of physical memory each worker process consumes, to a few thousand with mod_worker_mpm. If you are mixing mod_worker_mpm with php you should research the options that your version of php was compiled with as there are known incompatibilities with php and mod_worker_mpm.

You will also have to be mindful of the timeouts in both Apache and Jetty. Comet style connections either simulate a slow POST request, so you'll have to tune Apache to be lenient towards that, as well as the size of the request body. GET style requests are also subject to timeout if nothing is transmitted from the origin server. You'll have to apply these timeouts on both sides of the reverse proxy connection, from the client to Apache, and from Apache to Jetty.

If I was deploying a solution like this I would either place the Jetty based Comet service on a different domain, using a load balancer to proxy multiple Jetty backends for added capacity and reliability, or I would use a different reverse proxy, say HAProxy, to act in Apaches stead, and direct requests to the various backends (Apache, Jetty), based on the URL.

Password protect app in jetty

Take a look at the full example here:

https://web.archive.org/web/20150120081913/http://docs.codehaus.org/display/JETTY/How+to+Configure+Security+with+Embedded+Jetty

The above is Web archive link, original link is now unavailable:

http://docs.codehaus.org/display/JETTY/How+to+Configure+Security+with+Embedded+Jetty

Programmatic configuration example from the above:

import org.mortbay.jetty.security.*;

Server server = new Server();

Connector connector = new SelectChannelConnector();
connector.setPort(8080);
server.setConnectors(new Connector[]{connector});

Constraint constraint = new Constraint();
constraint.setName(Constraint.__BASIC_AUTH);;
constraint.setRoles(new String[]{"user","admin","moderator"});
constraint.setAuthenticate(true);

ConstraintMapping cm = new ConstraintMapping();
cm.setConstraint(constraint);
cm.setPathSpec("/*");

SecurityHandler sh = new SecurityHandler();
sh.setUserRealm(new HashUserRealm("MyRealm",System.getProperty("jetty.home")+"/etc/realm.properties"));
sh.setConstraintMappings(new ConstraintMapping[]{cm});

WebAppContext webappcontext = new WebAppContext();
webappcontext.setContextPath("/mywebapp");
webappcontext.setWar("./path/to/my/war/orExplodedwar");
webappcontext.addHandler(sh);

HandlerCollection handlers= new HandlerCollection();
handlers.setHandlers(new Handler[]{webappcontext, new DefaultHandler()});

server.setHandler(handlers);
server.start();
server.join();

Best Answer

Related Solutions

Apache and jetty

Password protect app in jetty

Related Topic