debug.xtp

解压在c盘

<s1 title="Debugging">

<summarylist/>

<s2 title='How to get debugging information'>

<p>Resin can write debugging information to standard output or to any
file.  To add debugging information add a <var/log/> directive to the
resin.conf file.</p>

<example>
&lt;caucho.com>
  &lt;log id='/' href='stderr:'/>
&lt;/caucho.com>
</example>

<p><var/href/> can be any path.  stderr: is perhaps the most useful.
<var/id/> can select which portions of Resin to get logging
information.  Here are some useful patterns:</p>

<deftable>
<tr><td>/<td>Debug everything
<tr><td>/caucho.com/jsp<td>Debug jsp
<tr><td>/caucho.com/jsp/java<td>See the JSP generated Java
<tr><td>/caucho.com/jsp/js<td>See the JSP generated Java
<tr><td>/caucho.com/xsl<td>XSL debugging
<tr><td>/caucho.com/tcp-server
    <td>See thread creation and deletion
<tr><td>/caucho.com/http
    <td>HTTP related information
</deftable>

</s2>

<s2 title="Exceptions don't have line numbers">

<p>For debugging, it is crucial to get proper line numbers.
Unfortunately, Java JITs (just-in-time compilers) remove the line
numbers.</p>

<p>For development we recommend you turn jit compiling off.  Start
the server with the JIT compiler turned off.  On Unix you can use:</p>

<example>
unix> httpd.sh -nojit
</example>

</s2>

<s2 title="How do I keep the generated .java files?">

<p>The generated .java files are put in <var/&lt;work-dir>/>.  By
default, that's <var//tmp/caucho/> on Unix and <var/\temp\caucho/> on
Windows.</p>

</s2>

<s2 title="How do I run Resin with a debugger?">

<p>Eric Hansen writes:</p>

<p>A lot of people have been asking about a suitable debugging environment for
resin.  I have been using JPadPro with the updated version of jdb.  (I found
that the jdb.exe that ships with the JDKs 1.2.2 do not like all
the classloading that happens in a servlet engine.)</p>

<p>Instead, try using the JavaTM Platform Debugger Architecture (JPDA)
http://www.javasoft.com/products/jpda/.</p>

<p>Just unzip the executables, dlls, and docs files in some directory.  I chose
c:\jdb.  My project class files are in: c:\local, my resin1.1 files are in:
c:\resin1.1, and jdk1.2.2 files are in c:\jdk1.2.2.</p>

<p>To start up the debugger issue the following command (you may need
additional classfiles in the classpath, etc.):</p>

<example>
C:\jdb\bin\jdb.exe -classpath
"C:\resin1.1\lib\jdk12.jar;C:\resin1.1\lib\jsdk.jar;
C:\resin1.1\lib\jsdk22.jar;C:\resin1.1\lib\resin.jar;
C:\jdk1.2.2\jre\lib\rt.jar;C:\jdk1.2.2\lib\tools.jar;
C:\local" com.caucho.server.http.HttpServer -conf
c:\resin1.1\conf\resin.conf
> run
</example>

<p>You can access the webserver at: http://localhost/ or
http://localhost:8080/, etc.  depending on the port number you picked.  You
should be able to issue the usual jdb commands.  Check the list of commands
by doing: help or ? at the jdb> prompt.</p>

<p>I use jdb with JPadPro (http://www.modelworks.com).  It has some built-in
scripts to work with jdb.  It is tailored to work with the jdb that ships
with the JDK, which has a slightly different response syntax from the JPDA
version of jdb.  Since all of JPadPro's commands are written in JavaScript,
you can easily modify the commands to parse the different command/response
syntax in JPDA.  Or you could even modify the jdb code to have it issue
similar commands, since JPDA ships with source code for jdb.  However, it's
probably easiest to modify the JavaScript.  (Check in
Tools/Java/JDK/Debugger/*, including onBreakPointHit, setBreakPoint.)  I
modified setBreakPoint, for example, to look like this:</p>

<example>
function BreakpointResult(data, breakpoint)
{
   var index = data.indexOf("Breakpoint set");
    var index2 = data.indexOf("Set breakpoint request");

    if ((index == -1) && (index2 == -1))
   {
      breakpoint.active = false;
      gOutput.writeMessage(breakpoint.getPath(),
                           breakpoint.getLineIndex(),
         "Setting breakpoint to inactive - breakpoint is " +
         "not positioned on a valid line");
   }
}
</example>

<p>This is because the old version of jdb issued the syntax: "Breakpoint
set...", and the new one issues the command "Set breakpoint request...".
You get the picture.</p>

<p>A similar formula should bear fruit for Visual Cafe, although they have
their own proprietary debugger.</p>

<p>Hope that's useful.</p>
<p>Eric</p>

</s2>

<s2 title="I've got a cryptic ServletException.  How do I get the full trace?">

<p>Eric Hansen writes:</p>

<p>Have you ever received a cryptic Exception message like this in your error logging due to an error in a JSP page: ???</p>

<results>
javax.servlet.ServletException
 at com.caucho.jsp.QPageContext.handlePageException(QPageContext.java:371)
 at work.ProgramOverview__jsp._jspService(ProgramOverview__jsp.java:115)
 at com.caucho.jsp.JavaPage.subservice(JavaPage.java, Compiled Code)
 at com.caucho.jsp.Page.service(Page.java, Compiled Code)
 at com.caucho.jsp.QServlet.service(QServlet.java, Compiled Code)
 at com.caucho.server.http.AbstractRequest.service(AbstractRequest.java, Compiled Code)
 at com.caucho.server.http.VirtualHost.service(VirtualHost.java, Compiled Code)
 at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java, Compiled Code)
 at com.caucho.server.http.QRequestDispatcher.forward(QRequestDispatcher.java, Compiled Code)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
 at com.caucho.server.http.AbstractRequest.service(AbstractRequest.java, Compiled Code)
 at com.caucho.server.http.VirtualHost.service(VirtualHost.java, Compiled Code)
 at com.caucho.server.http.Request.dispatch(Request.java, Compiled Code)
 at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java, Compiled Code)
 at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java, Compiled Code)
 at com.caucho.server.TcpConnection.run(TcpConnection.java, Compiled Code)
 at java.lang.Thread.run(Thread.java:479)
</results>

<p>You need to change your catch routine.  There is a method in ServletException called getRootCause().  This allows the developer of the servlet engine/JSP engine to embed a
regular Exception inside a ServletException, which gets carried along for the ride.</p>

<example>
catch(Exception e)
{
  logMessage(e,"",-1);
  if(e instanceof javax.servlet.ServletException)
  {
    Throwable et;
    et = ((javax.servlet.ServletException)e).getRootCause();
    if(et!=null&&et instanceof Exception)
    {
      logMessage(((Exception)et),"ROOT EXCEPTION",-1);
    }
  }
}
</example>
 
<p>(logMessage is some logging routine you write to do logging...  Could also be System.err.println...)
I was finding it quite difficult to debug JSP pages because I couldn't see what the underlying Exception was, just the ServletException which gets thrown from the JSP.  The
above modification (or something similar) exposes it.  I figure other people might have the same problem.</p>
 
<p>Hope that helps,</p>
<p>Eric</p>

</s2>

<s2 title="Thread Dumps">

<p>Java's thread dumps are a vital tool for server debugging.  Because
servlets are intrinsically multithreaded, it's very possible to create
deadlocks without realizing it, or to have runaway threads that
consume resources and cause OutOfMemory exceptions.  That's
especially true when you start adding third-party software like
databases, EJB, and Corba ORBs.</p>

<s3 title="Thread dump by sending a signal">

<p>On Windows, ctrl-break may produce a thread dump.</p>

<p>On Unix, "kill -QUIT" will produce a thread dump.  On the Linux IBM JDKs,
you'll need to signal one of the child processes.  On the Linux Sun JDK, you'll
need to kill the grandparent process of most of the threads:</p>

<example>
unix> ps -ef | grep java
ferg     14243 10792  0 Jan13 pts/0    00:00:00 sh -c /usr/java/bin/java
ferg     14244 14243  0 Jan13 pts/0    00:00:00 java -Dres
ferg     14253 14244  0 Jan13 pts/0    00:00:01 java -Dres
ferg     14254 14253  0 Jan13 pts/0    00:00:00 java -Dres
ferg     14255 14253  0 Jan13 pts/0    00:00:00 java -Dres
ferg     14256 14253  0 Jan13 pts/0    00:00:00 java -Dres
ferg     14257 14253  0 Jan13 pts/0    00:00:00 java -Dres
ferg     14258 14253  0 Jan13 pts/0    00:00:00 java -Dres
unix> kill -QUIT 14244
</example>

<p>The Solaris 1.3 JDK has a single process, so it's easy.</p>

<p>The Solaris 1.2 JDK has an extra quirk.  You need to run Resin in the
foreground (i.e. not using "start".)  Then you'll need to answer some
questions on the console.</p>
</s3>

<s3 title="Thread dump if signalling doesn't work">

<p>You get a thread dump without signalling the process by starting the JVM
with some extra arguments to allow a debugger to attach.  You can then attach
with the debugger at any time to get a thread dump.  This
technique works on all operating systems.</p>

<p>Here are some step by step instructions:</p>

<ol>
<li>Start Resin with some extra arguments that allow a debugger to attach:

<example>
$RESIN_HOME/bin/httpd -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5432
</example>

<li>Wait until you believe the application is in a state of deadlock
or has runaway threads.

<li>In another terminal (window), use jdb to connect to the running instance of Resin:

<example>
$JAVA_HOME/bin/jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5432
</example>

jdb will show something like:

<example>
Set uncaught java.lang.Throwable
Set deferred uncaught java.lang.Throwable
Initializing jdb ...
>
</example>

<li>Use the "suspend" command and then the "where all" command to get
a thread dump:

<example>
> <bold>suspend</bold>

All threads suspended.
> <bold>where all</bold>