📄 troubleshoot.xtp
字号:
<document><header><product>resin</product><title>Troubleshooting</title><description><p>A list of symptoms and their possible resolution.</p></description></header><body><localtoc/><s1 title="Symptoms"><s2 title="Resin stops responding"><ul><li>There may be a thread deadlock problem, <a href="#thread-dump">obtain a thread dump</a>.</li><li>Enable <a href="#debug-log">full debug logging</a> and checkthe last log entries for hints about what the last thing to happen was.</li></ul></s2><s2 title="Resin keeps restarting"><ul><li>Enable <a href="#debug-log">full debug logging</a> and checkthe entries for an explanation of why Resin thinks it should restart.</li></ul></s2><s2 name="memory-leaks" title="java.lang.OutOfMemoryError exception, application runs out of memory"><ul><li>Use JVM startup arguments to <a href="jvm-tuning.xtp#memory">increase heap memory.</a></li><li>Obtain a <a href="#heap-dump">heap dump</a> todetermine which objects are not getting garbage collected.</li><li>Obtain a <a href="#thread-dump">thread dump</a> andcheck for unreleased threads that might be holding onto objects.</li></ul><p>An OutOfMemoryError exception is usually an indication that heap memory isbeing used up. Often this is from application code keeping references toobjects that are no longer needed, and the garbage collector does not freethem. A heap dump can help determine which code and which kinds of objects arebeing held.</p><p>If the heap dump or other monitoring tools reveal that the server and yourappliciation(s) actually are not running out of heap memory then anOutOfMemoryError indicates that then the JVM is running out of virtualmemory, i.e. an underlying malloc() call is failing.</p><p>Often this situation is indicated by using OS tools to show memory usage, theJVM itself indicates it has heap memory but the OS tool shows that the processis using a very large amount of memory. On Windows the task manager is used, on Unix <code>top</code> or <code>ps</code>.</p><p>The only non-heap allocations by the JVM (and therefore Resin and yourapplication) are the following:</p><ul><li>threads and particularly the thread stack takes up virtual memory</li><li>any JNI libraries might be calling malloc or mmap (or the windowsequivalent of mmap) and taking virtual memory. This includes many databasedrivers, and also some JNI code that Resin uses.</li><li>for .jar/.zip files (specifically ZipFile), the JDK allocates virtualmemory. If you have a large number of jars open, you can run into problems.It's conceivable that a getResourceAsStream for a jar file that wasn't closedwould use up .jar memory.</li></ul></s2><s2 name="server-gets-slow" title="After a while the server starts to go very slow"><ul><li>This may be a garbage collection issue. If you have a memory leak, then anexcessive number of objects may get created, causing the garbage collector touse up all of your CPU. If you're running out of memory, then the JVM willslowly halt (and continually GC) until it dies. <ul> <li>Monitor <a href="#garbage-collection">garbage collection</a>. </li><li>Obtain a <a href="#heap-dump">heap dump</a> to determine if objects are not getting garbage collected. </li><li>See <a href="jvm-tuning.xtp#garbage-collection">Garbage Collection</a> in the JVM Tuning section for more about garbage collecting. </li></ul></li><li>This may be a runaway thread or a request that is tying up resources. If athread does not return from a request, Resin will not be able to reuse thethread and will have less threads to service new requests. <ul> <li>Obtain a <a href="#thread-dump">thread dump</a> and check for unreleased threads that might be holding onto objects. </li></ul></li></ul></s2> <!-- server-gets-slow --><s2 name="cpu-spike" title="CPU spikes, excessive CPU usage"><ul><li>Obtain a <a href="#thread-dump">thread dump</a> andcheck for threads that are caught in tight loops.</li><li>Check for <a href="#server-gets-slow">garbage collection</a> issues.</li></ul></s2> <!-- cpu-spike --><s2 title="Sessions become null, losing session"><s3 title="Debug logging"><p>A first step is to enable <a href="#debug-log">debuglogging</a>. In particular the headers submitted by the browser for a requestcan reveal the state of the JSESSIONID for a client, and logging will also showwhen Resin recognizes, creates, and/or invalidates a session.</p></s3><s3 title="Resin configuration for sessions"><p>Another possiblity is that the <a config-tag="session-max"/> setting is toolow, and you are getting more users establishing sessions than you haveconfigured Resin for.</p><p>Yet another possibility is that the session is timing out, you can use the<a config-tag="session-timeout"/> tag to configure this.</p><example><web-app id='/'> ... <session-config> <!-- timeout after 120 minutes --> <session-timeout>120</session-timeout> <!-- up to 4096 sessions at once --> <session-max>4096</session-max> </session-config> ...</web-app></example></s3><s3 title="Application reloading"><p>Whenever a java source file, web.xml, or resin.xml changes then Resin willrestart the application. If this happens, your current sessions will be lostunless you have configured a persistent session store.</p></s3><s3 title="Browser cookie limitations"><p>Some users have reported that if their application uses a lot of cookies,the browser will start to discard older cookies to make room for the new. Thismay result in the browser discarding the cookie that Resin is using to keeptrack of the session.</p><p>Internet Explorer users are particularily prone to encountering this problem.</p><p>If your application uses a lot of cookies, the best solution is to reducethe number of cookies and size of cookie data. Resin uses a single cookie witha relatively small amount of data for tracking the session id of the user.Information that the application stores in cookies can be stored in theHttpSession object instead.</p><p>As a last resort, you may need to configure Resinto always use URL rewriting by setting <a config-tag="enable-cookies"/> tofalse. However URL rewriting is not recommended because of security issues,the high probabilty that the application is missing calls to cause therewriting on some pages, and because of the effect that rewriting has on theurl.</p><example><web-app id='/'> ... <session-config> <enable-cookies>false</enable-cookies> <enable-url-rewriting>true</enable-url-rewriting> </session-config> ...</web-app></example></s3><s3 title="Problems with cookie domains"><p>You may also lose your sessions if your cookie domains are incompatible.For example, if you have one server that uses cookie domain "hogwarts.com" andanother that uses "qa.hogwarts.com", the cookie in the browser for"hogwarts.com" will interfere with sessions on "qa.hogwarts.com". The solutionis to change the cookie domain "hogwarts.com" to "www.hogwarts.com".</p><p>You set the cookie domain in <a config-tag="session-config"/>.(Thanks Laura for providing this)</p></s3><s3 title="Conflicting cookie names"><p>If you are using Resin and another application server (such as Tomcat), youmay encounter a conflict because both of them are using the same cookie name(usually JSESSIONID) for the session tracking cookie.</p><p>Resin provides <a config-tag="session-cookie"/> and <a config-tag="ssl-session-cookie"/>to let you change the name of the cookie that Resin uses.</p><example title="Change the name of the cookie used for session tracking"> <cluster> ... <session-cookie>RJESSESSIONID</session-cookie></example></s3><s3 title="URL rewriting"><p>If you forget to rewrite a URL, a user who requires rewriting will lose theirsession as soon as they follow that URL.</p><p>Resin establishes an association between a session and a user's browser byestablishing a unique id that is returned back with each new request. This isaccomplished in one of two ways: using cookies or URL rewriting.</p><p>Resin first attempts to track the session of a user by sending the user'sbrowser a cookie containing the unique session id. </p><p>Sometimes Resin cannot establish a cookie, either because the user hasdisabled cookies in their browser or because the browser does not support them(as is the case with some HDML and WML browsers). If the cookie cannot beestablished then something called URL rewriting is used.</p><p>In this case, Resin rewrites every URL that it submits to the user so thatit contains a parameter named <var>_jsessionid</var>. Then for each incomingrequest the first thing it does is look for this parameter, and if it isavailable it knows a session has been established and it removes the parameterand uses it to find the users session object.</p><p>Rewriting requires the cooperation of the developer. The developer mustencode every URL reference so that Resin has an opportunity to put in the<var>_jsessionid</var> parameter.</p><example title="URL rewriting using JSTL"><%@ taglib prefix='c' uri='http://java.sun.com/jstl/core' %>Time to go <a href="<c:url value='home.jsp'/>">Home</a>!</example><example title="URL rewriting using Java scriptlet"><%String homeUrl = response.encodeURL("home.jsp");%><%-- the presentation --%>Time to go <a href="<%= homeUrl %>">Home</a>!</example></s3></s2> <!-- losing sessions --><s2 title="Specification version 1.3 of package javax.servlet, J2EE Specification, version 1.3 is not compatible with Resin"><p>See <a href="#classpath">Clean up the classpath</a></p></s2><s2 title="Unsupported major.minor version 48.0"><p>This error usually happens when a conflicting jar is found, see <a href="#classpath">Clean up the classpath</a></p><p>If the classpath is completely cleaned up, as suggested in thelink, then a jar or some other component of a jdk installationor older Resin installation is coming from somewhere else.</p><p>There may be a problem with some jar in your JAVA_HOME tree, ifyou have added anything there.There may be a conflicting jar in WEB-INF/lib/ of your webapp.</p><p>Another possibility is that you have not set JAVA_HOME, or if youhave then some component of a conflicting jdk installation (javacfor example, or the java executable itself) is getting used.</p><p>If on windows, check for stray copies of java.exe outside ofJAVA_HOME, for example in C:/WINDOWS/java.exe or anywhere else inyour PATH.</p></s2><s2 title="Problems reading POST data"><p>A first step is to enable <a href="#debug-log">debuglogging</a>. Debug logging will show the request coming into to Resin, andprovide some information on how Resin is dealing with the post.</p><p>It is important to make sure the encoding is set properly before reading POSTparameters.</p><p>The browser will always send back parameters in the same encoding asthe output page. Since the request doesn't include the encoding (an oversightin the HTTP spec), the application code needs to make sure the encodingmatches.</p><p>So the first thing to do is to determine that encoding your form page has whenit is sent to the browser. Your application should always specify that.Having established that, you will know what encoding the browser is going touse for the POST. (utf-8 is a natural choice for encoding here, I'm not surewhy you would use anything else).</p><p>Then before reading the POST parameters make sure you set the encoding tomatch. You can call request.setCharacterEncoding(encoding) to do that.</p></s2></s1><s1 title="Techniques">⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -