Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Jetty/Troubleshooting"

(Big Problems)
 
(6 intermediate revisions by 2 users not shown)
Line 2: Line 2:
  
 
== Big Problems ==
 
== Big Problems ==
 +
 +
{{Jetty FAQ
 +
| question = What about locked files on Windows?
 +
| answer = Easy! read this! http://wiki.eclipse.org/Jetty/Howto/Deal_with_Locked_Windows_Files
 +
}}
  
 
{{Jetty FAQ  
 
{{Jetty FAQ  
 
| question = Why isn't my application/servlet/content served?  
 
| question = Why isn't my application/servlet/content served?  
| answer = If you think your application is running, but you get a 404 response, make sure that you have correctly [[Jetty/Howto/SetContextPath|set the context path]].
+
| answer = To diagnose the problem:
 +
* If you think your application is running, but you get a 404 response, make sure that you have correctly [[Jetty/Howto/SetContextPath|set the context path]].
  
If you are clicking a link to access the application, then make sure you have not got a relative URL problem.  Remember that a link to foo/bar on a page at /myapp/page will go to /myapp/foo/bar.  If you want it to go to /myapp/page/foo/bar then you must make sure the browser is redirected from /myapp/page to /myapp/page/
+
* If you click a link to access the application, make sure you don't have a relative URL problem.  Remember that a link to foo/bar on a page at /myapp/page goes to /myapp/foo/bar.  If you want it to go to /myapp/page/foo/bar, make sure the browser is redirected from /myapp/page to /myapp/page/.
  
If you still cannot get your content, look in the requestlog to see the exact URL that is being requested.
+
* If you still cannot get your content, look in the requestlog to see the exact URL that is being requested.
  
If you receive a 503 Unavailable response, then there was an exception while deploying the webapplication. Check the log for for details.
+
* If you receive a 503 Unavailable response, an exception occurred while deploying the web application. Check the log for details.
 
}}
 
}}
  
 
{{Jetty FAQ  
 
{{Jetty FAQ  
 
| question = Jetty has locked up?  
 
| question = Jetty has locked up?  
| answer = If your requests are not getting any responses, then a frequent description of the problem is that "jetty locked up". In order to diagnose such problems, it is very important to work out exactly what has locked up.
+
| answer = If your requests are not getting any responses, a frequent description of the problem is that "Jetty locked up." To diagnose such problems, it is very important to work out exactly what has locked up.
  
You can test if the JVM has locked up completely by trying to use a tool like jconsole or jvisualvm to attach to the process.    If you cannot attach to the process, the it is likely something has gone wrong with the JVM and/or operating system rather than Jetty itself.
+
* You can test whether the JVM has locked up completely by trying to use a tool like Jconsole or jvisualvm to attach to the process.  
  
If you can attach to the JVM with jconsole and/or jvisualvm, then look to see how many threads are allocated and what task they are doing.  A frequent cause of such "lockups" is a slow database so that all the threads in the thread pool end up waiting for a JDBC connection from the connection pool.
+
** If you cannot attach to the process, it is likely something has gone wrong with the JVM and/or the operating system rather than Jetty itself.
  
You can test if Jetty is completely locked up by trying some simple requests and seeing if they are get a response.    Hitting http://thehost.com/favicon.ico or some other image directly is often a good way to see if jetty is still runningIf it is, then try some simple requests within the application that will use minimal features (no authentication, no database etc.) and see if any of those requests work.
+
** If you can attach to the JVM with Jconsole and/or jvisualvm, look to see how many threads are allocated and what tasks they are doingA frequent cause of lockups is a slow database so that all the threads in the thread pool end up waiting for a JDBC connection from the connection pool.
  
Finally telnet can be used as a fake HTTP client to see if connections are being accepted.  If you telnet to the port (eg 80 or 8080) and you see a "Connected to www.example.com" message, then Jetty is still accepting connections.   Then try typing a request like "OPTION * HTTP/1.0" and hit Enter twice to see if you get a HTTP response.  eg
+
* You can test whether Jetty is completely locked up by trying some simple requests to see if they get a response. Opening http://thehost.com/favicon.icon or some other image directly is often a good way to see if Jetty is still running.  If it is, try some simple requests within the application that use minimal features (no authentication, no database, for example) and see if any of those requests work.
 +
 
 +
* Finally, you can use telnet as a fake HTTP client to see if Jetty is accepting connections.  If you telnet to the port (80 or 8080) and you see a "Connected to www.example.com" message, Jetty is still accepting connections. Next try typing a request like "OPTION * HTTP/1.0" and press '''Enter''' twice to see if you get an HTTP response:
  
 
   <pre>
 
   <pre>
Line 39: Line 47:
 
   </pre>
 
   </pre>
  
Check that the "Server" in the response field is Jetty (and not a load balancer etc.).
+
Check that the ''Server'' in the response field is Jetty (and not a load balancer, etc.).
  
Doing tests like these will help narrow down exactly which component has "locked up".  Getting a thread dump (with jstack or ctl-\ or jvisualvm) is also invaluable to diagnose what the threads are doing.
+
Doing tests like these helps narrow down exactly which component has locked up.  Getting a thread dump (with jstack or ctl-\ or jvisualvm) is also invaluable to diagnose what the threads are doing.
  
 
}}
 
}}
Line 49: Line 57:
 
{{Jetty FAQ
 
{{Jetty FAQ
 
| question = JSP support not configured?
 
| question = JSP support not configured?
| answer = JSP is an option for Jetty.  Firstly, the jars need to be present in the lib/jsp directory, but currently the JSP jars are not distributed with the jetty@eclipse download (soon will be), but they are available as part of the [[Jetty/Starting/Downloads|jetty@codehaus jetty-hightide download]].  Secondly, the JSP option needs to be specified for the [[Jetty/Howto/Run_Jetty|start.jar command line]].
+
| answer = JSP is an option for Jetty.  You must specify the JSP option for the [[Jetty/Howto/Run_Jetty|start.jar command line]]. (As of Jetty 7.1.x, the jetty@eclipse download includes the JSP Jars.)
  
If JSP is not correctly configured then each context started will produce an error message like:  
+
If JSP is incorrectly configured, each context started produces an error message like:  
 
<pre>
 
<pre>
 
INFO::NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
 
INFO::NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
 
</pre>
 
</pre>
A request to a JSP will generate a 500 response with the message "500 JSP support not configured"
+
A request to a JSP generates a 500 response with the message "500 JSP support not configured"
 
}}
 
}}
  
 +
{{Jetty FAQ
 +
| question = Why does StressTest.java fail on Mac OS?
 +
| answer = StressTest in jetty-server might fail on Mac OS X due to an insufficient port range. Most operating systems have a limit of 65535 available TCP/IP ports.
  
 +
Read the following wikipedia entry for details:
 +
 +
http://en.wikipedia.org/wiki/Ephemeral_port
 +
 +
[...]The IANA suggests 49152 to 65535 as "dynamic and/or private ports.[...]
 +
 +
[...]Many Linux kernels use 32768 to 61000.[...]
 +
 +
We have fixed the test code to make it run successfully on Mac OS. If it nonetheless fails on your Mac OS, raise the port range by executing the following two commands in a terminal:
 +
 +
<pre>
 +
sudo sysctl -w net.inet.ip.portrange.first=32768
 +
sudo sysctl -w net.inet.ip.portrange.hifirst=32768
 +
</pre>
 +
 +
It seems that Apple raised the limits for Mac OS Lion, so on Lion it should work from scratch. If not, apply the <tt>sysctl</tt> commands and retry.
 +
 +
}}
  
 
== Logs and Warnings ==  
 
== Logs and Warnings ==  
Line 65: Line 94:
 
| question = Why do I get JVM Bugs reported?
 
| question = Why do I get JVM Bugs reported?
 
| answer = Yes!  
 
| answer = Yes!  
There are several NIO bugs in the JVM (specially for linux) that will not be fixed in the 1.6.x series. Jetty has implemented a number of [[Jetty/Feature/JVM_NIO_Bug|JVM NIO Bug work arounds]] that keep a jetty server working efficiently in the presence of these problems.
+
There are several NIO bugs in the JVM (especially for Linux) that are not fixed in the 1.6.x series. Jetty has implemented a number of [[Jetty/Feature/JVM_NIO_Bug|JVM NIO Bug work arounds]] that keep a Jetty server working efficiently in the presence of these problems.
 
}}
 
}}
  
 
{{Jetty FAQ  
 
{{Jetty FAQ  
 
| question = Why do I get a "Save could not be completed" error in Eclipse whenever I try to save a file while Jetty is running?  
 
| question = Why do I get a "Save could not be completed" error in Eclipse whenever I try to save a file while Jetty is running?  
| answer = This is a limitation of Windows -- having a file open in one process means that you can't write to that same file with another process. Since Jetty has mapped the file to its cache, which prevents the file from being edited, you'll need to turn off caching to work around the problem. You can turn off caching in the default servlet by setting <code>&lt;useFileMappedBuffer&gt;</code> to <code>false</code> in [[Jetty/Reference/webdefault.xml|webdefault.xml]].
+
| answer = This is a limitation of Windows -- having a file open in one process means that you can't write to that same file with another process. Since Jetty has mapped the file to its cache, which prevents the file from being edited, you need to turn off caching to work around the problem. You can turn off caching in the default servlet by setting <code>&lt;useFileMappedBuffer&gt;</code> to <code>false</code> in [[Jetty/Reference/webdefault.xml|webdefault.xml]].
 
}}
 
}}

Latest revision as of 16:29, 20 September 2011



Big Problems

Question Mark.png What about locked files on Windows?


Question Mark.png Why isn't my application/servlet/content served?

To diagnose the problem:
  • If you think your application is running, but you get a 404 response, make sure that you have correctly set the context path.
  • If you click a link to access the application, make sure you don't have a relative URL problem. Remember that a link to foo/bar on a page at /myapp/page goes to /myapp/foo/bar. If you want it to go to /myapp/page/foo/bar, make sure the browser is redirected from /myapp/page to /myapp/page/.
  • If you still cannot get your content, look in the requestlog to see the exact URL that is being requested.
  • If you receive a 503 Unavailable response, an exception occurred while deploying the web application. Check the log for details.


Question Mark.png Jetty has locked up?

If your requests are not getting any responses, a frequent description of the problem is that "Jetty locked up." To diagnose such problems, it is very important to work out exactly what has locked up.
  • You can test whether the JVM has locked up completely by trying to use a tool like Jconsole or jvisualvm to attach to the process.
    • If you cannot attach to the process, it is likely something has gone wrong with the JVM and/or the operating system rather than Jetty itself.
    • If you can attach to the JVM with Jconsole and/or jvisualvm, look to see how many threads are allocated and what tasks they are doing. A frequent cause of lockups is a slow database so that all the threads in the thread pool end up waiting for a JDBC connection from the connection pool.
  • You can test whether Jetty is completely locked up by trying some simple requests to see if they get a response. Opening http://thehost.com/favicon.icon or some other image directly is often a good way to see if Jetty is still running. If it is, try some simple requests within the application that use minimal features (no authentication, no database, for example) and see if any of those requests work.
  • Finally, you can use telnet as a fake HTTP client to see if Jetty is accepting connections. If you telnet to the port (80 or 8080) and you see a "Connected to www.example.com" message, Jetty is still accepting connections. Next try typing a request like "OPTION * HTTP/1.0" and press Enter twice to see if you get an HTTP response:
   # telnet blogs.webtide.com 80
   Trying 72.32.76.94...
   Connected to blogs.webtide.com.
   Escape character is '^]'.
   OPTION * HTTP/1.0
   HTTP/1.1 503 Service Unavailable
   Cache-Control: must-revalidate,no-cache,no-store
   Content-Type: text/html;charset=ISO-8859-1
   Content-Length: 1287
   Server: Jetty(7.0.0.v20091005)
   

Check that the Server in the response field is Jetty (and not a load balancer, etc.).

Doing tests like these helps narrow down exactly which component has locked up. Getting a thread dump (with jstack or ctl-\ or jvisualvm) is also invaluable to diagnose what the threads are doing.



Question Mark.png JSP support not configured?

JSP is an option for Jetty. You must specify the JSP option for the start.jar command line. (As of Jetty 7.1.x, the jetty@eclipse download includes the JSP Jars.)

If JSP is incorrectly configured, each context started produces an error message like:

INFO::NO JSP Support for /, did not find org.apache.jasper.servlet.JspServlet
A request to a JSP generates a 500 response with the message "500 JSP support not configured"


Question Mark.png Why does StressTest.java fail on Mac OS?

StressTest in jetty-server might fail on Mac OS X due to an insufficient port range. Most operating systems have a limit of 65535 available TCP/IP ports.

Read the following wikipedia entry for details:

http://en.wikipedia.org/wiki/Ephemeral_port

[...]The IANA suggests 49152 to 65535 as "dynamic and/or private ports.[...]

[...]Many Linux kernels use 32768 to 61000.[...]

We have fixed the test code to make it run successfully on Mac OS. If it nonetheless fails on your Mac OS, raise the port range by executing the following two commands in a terminal:

sudo sysctl -w net.inet.ip.portrange.first=32768
sudo sysctl -w net.inet.ip.portrange.hifirst=32768
It seems that Apple raised the limits for Mac OS Lion, so on Lion it should work from scratch. If not, apply the sysctl commands and retry.

Logs and Warnings

Question Mark.png Why do I get JVM Bugs reported?

Yes! There are several NIO bugs in the JVM (especially for Linux) that are not fixed in the 1.6.x series. Jetty has implemented a number of JVM NIO Bug work arounds that keep a Jetty server working efficiently in the presence of these problems.


Question Mark.png Why do I get a "Save could not be completed" error in Eclipse whenever I try to save a file while Jetty is running?

This is a limitation of Windows -- having a file open in one process means that you can't write to that same file with another process. Since Jetty has mapped the file to its cache, which prevents the file from being edited, you need to turn off caching to work around the problem. You can turn off caching in the default servlet by setting <useFileMappedBuffer> to false in webdefault.xml.

Back to the top