RESIN3.1配置說明及常見性問題解決方案

1、Resin 3.1 中文文檔目錄1. Resin 3.1 配置文件說明22. Resin 3.1 FAQ癥狀81.1. Resin停止響應81.2. Resin不停重啟動81.3. java.lang.OutOfMemoryError錯誤，應用程序內存溢出81.4. 運行一會兒，服務器開始變得非常慢91.5. CPU尖峰，高的CPU使用率91.6. 會話(sessions)變成null,會話丟失101.6.1. 調試日志101.6.2. Resin會話配置101.6.3. 應用程序重載111.6.4. 瀏覽器cookie的局限111.6.5. cookie域名的問題121.6.6. cooki

2、e名稱沖突121.6.7. URL重寫131.7. J2EE規(guī)范，javax.servlet包規(guī)范1.3和Resin不兼容141.8. Unsupported major.minor version 48.0141.9. 讀取POST數據的問題142. Resin 3.1 FAQ技巧方法152.1. 啟用調試日志152.1.1. 服務器和所有應用程序的完全調試日志152.1.2. 一個web應用程序的完全調試日志152.2. 線程轉儲162.2.1. 使用JDK5工具轉儲線程162.2.2. 通過發(fā)送一個信號轉儲線程172.2.3. 如果發(fā)送信號無效時的線程轉儲172.3. 內存溢出和垃圾收集

3、222.3.1. -verbosegc232.3.2. 使用堆轉儲檢查內存使用242.3.3. 理解 java.hprof.txt 文件中的棧信息242.3.4. 理解 java.hprof.txt 文件中的CPU信息262.3.5. 監(jiān)視垃圾回收272.3.6. 增加堆內存282.4. 清空classpath282.5. 監(jiān)視HTTP傳輸282.6. 使用一個外部編譯器292.7. 調整棧內存避免線程限制292.8. 使用操作系統的 netstat 命令獲得當前 TCP/IP 端口的使用302.8.1. 連接狀態(tài)302.8.2. 端口使用311. Resin 3.1 配置文件說明resin

4、xmlns= xmlns:resin= 2s!- Security providers.- - .ernal.ssl.Provider- -!- 去掉注釋，如果你使用resin提供的xml應用- - - . !- - SSL端口配置: - - - - keys/gryffindor.crt - keys/gryffindor.key - test123 - - - -Xmx256m -Xss1m -Xdebug -Dcom.sun.management.jmxremote !- Uncomment to enable admin heap dumps 去掉這個如果你想管理內存堆的

5、傾倒 - -agentlib:resin - -Dcom.sun.management.jmxremote 1M 256 65s 128 15s !- - 如果使用的是UNIX,這里是啟動的帳號和用戶組. - resin - resin - !- 為了安全, 你可以為SSL會話(SSL sessions)定義一個不同的cookie. - SSL_JSESSIONID - !- 啟用周期性的服務器狀態(tài)檢查和死鎖檢查，所有的服務器可以添加 來檢查。 - !- http:/localhost:8080/test-ping.jsp - web-app-default false !- 安全原因, 在c

6、ookies中設置HttpOnly標志 - - true true true /web-app-default !- 簡單的數據池配置 - The JDBC name is java:comp/env/jdbc/test jdbc/mysql jdbc:mysql:/localhost:3306/test 8 20 30s - WEB-INF jdbc/test 2. Resin 3.1 FAQ癥狀1.1. Resin停止響應可能是一個線程死鎖的問題，應該進行線程轉儲。啟用完全調試日志模式，檢查日志最后的紀錄看看發(fā)生了什么。 1.2. Resin不停重啟動啟用完全調試日志模式，檢查記錄看看Re

7、sin為什么不停的重啟它。 1.3. java.lang.OutOfMemoryError錯誤，應用程序內存溢出使用JVM啟動參數增加堆(heap)內存。轉儲堆，看看那個對象無法被垃圾回收器無法回收。轉儲線程，檢查占用著對象的不能釋放的線程一個OutOfMemoryError錯誤通常意味著堆（heap）內存被用盡。一般是應用程序代碼保持了對不在使用的對象的引用，垃圾回收器無法對其進行回收。轉儲堆，能夠查到什么代碼和什么種類的對象被占用了。如果對轉儲或者其它監(jiān)視工具顯示服務器和你的程序實際沒有超出堆內存，那么 OutOfMemoryError意味著JVM超出了虛擬內存，也就是底層的malloc(

8、)調用失敗。通常這種情況，通過使用操作系統工具顯示內存使用，JVM自己能夠顯示其自己的堆內存，但是操作系統工具確顯示進程占用了大量的內存。在Windows下使用任務管理器，Unix下使用top或者ps 命令。 JVM無法進行堆內存分配可能有如下原因：線程，特別是線程堆占用虛擬內存。JNI庫可能調用malloc或者nmap占用虛擬內存。這包括很多數據庫驅動，也包含一些Resin使用的JNI代碼。對于.jar/.zip文件，JDK要分配虛擬內存。如果你打開了大量的jar文件，你可能會遇到問題。可以想到用于打開jar的getResourceAsStream沒有關閉將會耗盡.jar內存。 1.4. 運

9、行一會兒，服務器開始變得非常慢 這可能是一個垃圾回收問題。如果你的內存缺乏，然后又創(chuàng)建了大量的對象，這導致垃圾回收器耗盡CPU。如果你內存溢出，JVM將會慢慢停止(連續(xù)地進行垃圾收集)直到它死亡。 監(jiān)視垃圾收集。 轉儲堆，看看是否是有對象無法被回收。 參看JVM垃圾回收參數調整的文檔獲得更多垃圾回收的信息。 可能有一個死循環(huán)的線程或者一個請求耗盡資源?；貞粋€請求的線程如果不能返回，Resin就沒法再次利用它，那么可用來服務的線程就會越來越少。 進行線程轉儲，檢查可能占用對象的無法釋放的線程。 1.5. CPU尖峰，高的CPU使用率 轉儲線程，檢查那些線程在無限循環(huán)。 檢查垃圾收集的部分。 1

10、.6. 會話(sessions)變成null,會話丟失 1.6.1. 調試日志首先啟用調試日志。特別是瀏覽器請求提交的頭信息能夠顯示一個客戶端的JSESSIONID狀態(tài)，日志也能說明Resin什么時候識別、創(chuàng)建和失效一個會話。 1.6.2. Resin會話配置另一個可能是session-max設置過低，導致當前用戶建立會話的數量大于你設置的這個值。另一個可能是會話超時，你可以通過session-timeout標簽來配置它。 . 120 4096 . 1.6.3. 應用程序重載無論何時，一個java源文件、web.xml或者resin.xml改變，Resin都會重啟應用程序。如果這個情況發(fā)生，你

11、當前的會話就會丟失，除非你配置了一個持久性會話存儲。 1.6.4. 瀏覽器cookie的局限一些用戶報告，如果他們的應用程序使用大量的cookie，瀏覽器將會丟棄舊的cookie為新的騰出空間。這就會出現瀏覽器丟失了Resin 用來跟蹤會話的cookie。IE瀏覽器用戶特別容易遇到這個問題。如果你的應用程序使用大量的cookie，最好的解決方案就是減少cookie數量和 cookie數據的大小。Resin使用一個單一的cookie其存儲相對很少的數據用拉跟蹤用戶的會話ID。應用程序存儲在cookie中的信息可以使用HttpSession對象來存儲。作為最后的手段，你可以配置Resin總是使用U

12、RL重寫，這需要把enable-cookies設置成 false。由于安全的原因URL重寫式不推薦的，因為重寫URL增加了重寫某些頁面丟失調用的高可能性。 . false true . 1.6.5. cookie域名的問題如果你的cookie域名不兼容也可能丟失會話。例如，如果你有一個服務器使用cookie域名，另一個使用 ，在瀏覽器中的cookie會干擾在上的會話。方法是改變cookie域名為。 你可以在session-config標簽中設置 cookie域名。 1.6.6. cookie名稱沖突如果你使用Resin和另一個應用服務器（例如Tomcat），你可能遇到這個沖突，因為它們使用相同

13、的cookie名稱(他通常是 JSESSIONID) 來跟蹤會話。Resin提供session-cookie 和 ssl-session-cookie讓你可以改變Resin使用的cookie名稱。改變用來跟蹤會話的cookie名稱的片斷： . RJESSESSIONID 1.6.7. URL重寫如果你忘記了重寫一個URL，一個需要重寫的用戶當訪問到這個URL時將丟失他們的會話。Resin在一個用戶瀏覽器和一個會話 (session)之間建立一個關聯，是通過為每一個新請求返回一個惟一的id。這可通過兩種方式之一來完成：使用cookie或者URL重寫。 Resin首先嘗試向用戶瀏覽器發(fā)送一個包含惟

14、一會話ID的cookie來跟蹤一個用戶的會話。有時Resin不能建立cookie，不是因為用戶在其瀏覽器禁用了cookies就是因為某些瀏覽器不支持它們（例如一些HDML和WML瀏覽器)。如果cookie不能建立那么就會使用URL重寫。在這種情況下，Resin重寫每一個它提交給用戶的URL，讓其包含一個名稱為_jsessionid的參數。然后為每一個新來的請求做的第一件事就是查找這個參數，如果這個參數存在那么就知道一個會話已經建立，它移出參數并使用它來查找用戶會話對象。URL重寫需要開發(fā)者的協同合作。開發(fā)者必須編碼每一個URL 引用讓Resin有一個合適的機會放置_jsessionid參數。

15、使用JSTL實現URL重寫 Time to go a href=c:url _fcksavedurl=c:url _fcksavedurl=Home! 使用Java scriptlet實現URL重寫 Time to go a href=Home! 1.7. J2EE規(guī)范，javax.servlet包規(guī)范1.3和Resin不兼容參看清除classpath環(huán)境變量。 1.8. Unsupported major.minor version 48.0這個錯誤經常在發(fā)現一個沖突的jar時發(fā)生，參看清除classpath環(huán)境變量。 如果環(huán)境變量classpath被完全清除，然而一個JDK或者舊Resin

16、的一個jar或者一些其它組件出現在的什么地方，如果你已經在那些地方添加了，在你的JAVA_HOME樹里的一些jar可能有一個問題，那里可有一個和你的web程序WEB-INF/lib/目錄下沖突的jar。另一種可能是你還沒設置JAVA_HOME，或者你使用了一個沖突的JDK的一些組件。如果在Windows上，檢查JAVA_HOME之外的java.exe的拷貝，例如C:/WINDOWS/java.exe或者在你PATH路徑里其它地方的java.exe。 1.9. 讀取POST數據的問題首先啟用調試日志。調試日志會顯示發(fā)送到Resin的請求，提供一些Resin如何處理這些數據的信息。最重要的是確保在

17、讀取POST參數之前編碼設置正確。瀏覽器總是發(fā)回和輸出頁面編碼相同的參數。因為請求不包含編碼，應用程序代碼需要確保編碼匹配。因此第一件事就是確定發(fā)送到瀏覽器的表單的編碼。你的應用程序總應該指定它。一旦你指定了它，你就知道瀏覽器POST使用編碼。(這里UTF-8是個自然的編碼選擇，我不能確信你為什么使用其它的編碼)。在讀取POST參數之前確保設置了正確的編碼，你可以調用request.setCharacterEncoding(encoding)來設置編碼。 2. Resin 3.1 FAQ技巧方法 2.1. 啟用調試日志Resin使用JDK日志工具提供了大量的診斷信息。通過使用一個空名稱（匹配所

18、有名字）可以啟用完全調試日志，調試級別為“全部”。因為將會產生大量信息，把這些信息放在一個單獨的文件中比較好。 2.1.1. 服務器和所有應用程序的完全調試日志下面的配置每天創(chuàng)建一個日志，當一個問題出現時用來查找問題出現在什么地方。因為日志配置在resin.xml中，日志的捕捉是服務器和其上所有應用程序的。日志輸出的信息在 $RESIN_HOME/log/debug.log。 resin xmlns= 有其它一些的日志配置選項，請參看Resin日志文檔。 2.1.2. 一個web應用程序的完全調試日志通常你一般僅需要一個程序輸出的調試日志。日志配置記錄放在/WEB-INF/web.xml中，那

19、么僅這個web應用程序的日志信息被輸出到日志文件中。下面的配置每天創(chuàng)建一個調試日志，位置/WEB-INF /work/debug.log。!- /WEB-INF/web.xml - . . 2.2. 線程轉儲如果應用程序好像有問題或者超出資源泄露，線程轉儲能夠顯示服務器的狀態(tài)。對于服務器調試Java的縣城轉儲是一個重要的工具。因為 Servlet是多線程的，沒有處理好的話很可能出現死鎖，或者出現死循環(huán)和導致內存溢出錯誤。特別是你使用了第三方軟件例如數據庫、EJB和Corba ORBs。 2.2.1. 使用JDK5工具轉儲線程在JDK5里可以使用jps和jstack，一個快捷的命令行方法獲得當前

20、所有線程的堆棧跟蹤信息。# jps12903 Jps20087 Resin# jstack 20087Attaching to process ID 20087, please wait.Debugger attached successfully.Client compiler detected.JVM version is 1.5.0-beta2-b51Thread 12691: (state = BLOCKED) - java.lang.Object.wait(long) (Compiled frame; information may be imprecise) - com.cauch

21、o.util.ThreadPool.runTasks() bci=111, line=474 (Compiled frame) - com.caucho.util.ThreadPool.run() bci=85, line=423 (Interpreted frame) - java.lang.Thread.run() bci=11, line=595 (Interpreted frame) Thread 12689: (state = BLOCKED) - java.lang.Object.wait(long) (Compiled frame; information may be impr

22、ecise) - com.caucho.util.ThreadPool.runTasks() bci=111, line=474 (Compiled frame) - com.caucho.util.ThreadPool.run() bci=85, line=423 (Interpreted frame) - java.lang.Thread.run() bci=11, line=595 (Interpreted frame) . 2.2.2. 通過發(fā)送一個信號轉儲線程在 Windows, ctrl-break會產生線程轉儲。在Unix, kill -QUIT 會產生線程轉儲。 2.2.3.

23、如果發(fā)送信號無效時的線程轉儲你可以在啟動JVM時指定附加的參數允許附加一個調試器而不是發(fā)送信號來轉儲線程。你然后在任何時候附加調試器來得到線程轉儲。 這種方法在所有的操作系統上得到支持。 下面是是逐步的指導: 1. 使用附加的參數啟動Resin來允許一個調試器附加: resin.xml for debugging resin xmlns= -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5432 2. 等待，直到你認為應用程序出現了死鎖或者失去控制。 3. 打開另一個終端 (window), 使用jdb連接正在運

24、行的Resin實例： $JAVA_HOME/bin/jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5432 jdb會顯示類似如下信息: Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb . 4. 使用 suspend 命令， 然后 where all命令獲得一個線程轉儲: 例子: jdbc suspend suspend All threads suspended. where all

25、 tcpConnection-6862-3: 1 java.lang.Object.wait (native method) 2 com.caucho.server.TcpServer.accept (TcpServer.java:650) 3 com.caucho.server.TcpConnection.accept (TcpConnection.java:208) 4 com.caucho.server.TcpConnection.run (TcpConnection.java:131) 5 java.lang.Thread.run (Thread.java:536) tcpConnec

26、tion-543-2: 1 java.lang.Object.wait (native method) 2 com.caucho.server.TcpServer.accept (TcpServer.java:650) 3 com.caucho.server.TcpConnection.accept (TcpConnection.java:208) 4 com.caucho.server.TcpConnection.run (TcpConnection.java:131) 5 java.lang.Thread.run (Thread.java:536) . 5. 使用 resume 命令來恢復

27、進程 resume Unix 用戶(和Windows上的Cygwin用戶)可以使用一個腳本:resin-thread-dump.sh #!/bin/shecho -e suspendnwhere allnresumenquit | $JAVA_HOME/bin/jdb -connect com.sun.jdi.SocketAttach:hostname=localhost,port=5432 雖然沒有進行過嚴格基準測試，好像使用線程轉儲參數啟動的JVM在性能上影響不大。2.2.4. 理解線程轉儲在任何情況下，你會最終得到類似如下的跟蹤調試信息(不同的JDK有稍微的差別): Full threa

28、d dump: tcpConnection-8080-2 daemon waiting on monitor 0xbddff000.0xbddff8c4 at java.lang.Object.wait(Native Method) at com.caucho.server.TcpServer.accept(TcpServer.java:525) at com.caucho.server.TcpConnection.accept(TcpConnection.java:190) at com.caucho.server.TcpConnection.run(TcpConnection.java:1

29、36) at java.lang.Thread.run(Thread.java:484) tcpConnection-8080-1 daemon waiting on monitor 0xbdfff000.0xbdfff8c4 at java.lang.Object.wait(Native Method) at com.caucho.server.TcpServer.accept(TcpServer.java:525) at com.caucho.server.TcpConnection.accept(TcpConnection.java:190) at com.caucho.server.TcpConnection.run(TcpConnection.java:136) at java.lang.Thread.run(Thread.java:484) tcpConnection-8080-0 daemon waiting on monitor 0xbe1ff000.0xbe1ff8c4 at java.lang.Object.wait(Native Method) at com.caucho.server.TcpServer.accept(TcpServer.java:525) at com.caucho.serve