• <input id="qucwm"><u id="qucwm"></u></input>
  • <menu id="qucwm"></menu>
  • <input id="qucwm"><tt id="qucwm"></tt></input>
  • <input id="qucwm"><acronym id="qucwm"></acronym></input>
  • 標簽 ‘ tomcat

    深度解析Java線程池的異常處理機制

    作者:aCoder2013 首發博客地址:https://github.com/aCoder2013/blog/issues/3

    前言

    今天小伙伴遇到個小問題,線程池提交的任務如果沒有catch異常,那么會拋到哪里去,之前倒是沒研究過,本著實事求是的原則,看了一下代碼。

    閱讀全文

    Tomcat-connector的微調(3): processorCache與socket.processorCache

    tomcat在處理每個連接時,Acceptor角色負責將socket上下文封裝為一個任務SocketProcessor然后提交給線程池處理。在BIO和APR模式下,每次有新請求時,會創建一個新的SocketProcessor實例(在之前的tomcat對keep-alive的實現邏輯里也介紹過可以簡單的通過SocketProcessorSocketWrapper實例數對比socket的復用情況);而在NIO里,為了追求性能,對SocketProcessor也做了cache,用完后將對象狀態清空然后放入cache,下次有新的請求過來先從cache里獲取對象,獲取不到再創建一個新的。

    這個cache是一個ConcurrentLinkedQueue,默認最多可緩存500個對象(見SocketProperties)??梢酝ㄟ^socket.processorCache來設置這個緩存的大小,注意這個參數是NIO特有的。

    接下來在SocketProcessor執行過程中,真正的業務邏輯是通過一個org.apache.coyote.Processor的接口來封裝的,默認這個Processor的實現是org.apache.coyote.http11.Http11Processor。我們看一下SocketProcessor.process(...)方法的大致邏輯:

    閱讀全文

    Tomcat-connector的微調(2): maxConnections, maxThreads

    1) 最大連接數

    tomcat的最大連接數參數是maxConnections,這個值表示最多可以有多少個socket連接到tomcat上。BIO模式下默認最大連接數是它的最大線程數(缺省是200),NIO模式下默認是10000,APR模式則是8192(windows上則是低于或等于maxConnections的1024的倍數)。如果設置為-1則表示不限制。

    在tomcat里通過一個計數器來控制最大連接,比如在Endpoint的Acceptor里大致邏輯如下:

    閱讀全文

    Tomcat-connector的微調(1): acceptCount參數

    對于acceptCount這個參數,含義跟字面意思并不是特別一致(個人感覺),容易跟maxConnections,maxThreads等參數混淆;實際上這個參數在tomcat里會被映射成backlog:

    static {
        replacements.put("acceptCount", "backlog");
        replacements.put("connectionLinger", "soLinger");
        replacements.put("connectionTimeout", "soTimeout");
        replacements.put("rootFile", "rootfile");
    }
    

    backlog表示積壓待處理的事物,是socket的參數,在bind的時候傳入的,比如在Endpoint里的bind方法里:

    閱讀全文

    Tomcat對keep-alive的實現邏輯

    Tomcat的connector實現邏輯蠻復雜的,有很多種狀態總記不住,每次遇到網絡相關的問題都要翻一遍代碼,這次結合一個案例看看tomcat的三種connector的實現方式。

    這個案例在畢玄的blog里也提到了,背景是某應用上游有個用c寫的模塊與server端tomcat進行http通訊,這個應用tomcat配置的connector是apr模式。之前一直運行的很穩定,但一次前端擴容后,導致后端的tomcat全部阻塞在下面的堆棧上:

    閱讀全文

    tomcat啟動時檢測到循環繼承而棧溢出的問題

    一個用戶在使用tomcat7054版本啟動的時候遇到的錯誤:

    Caused by: java.lang.IllegalStateException: 
    Unable to complete the scan for annotations for web application [/test] 
    due to a StackOverflowError. Possible root causes include a too low setting 
    for  -Xss and illegal cyclic inheritance dependencies. 
    
    The class hierarchy being processed was 
    
    [org.jaxen.util.AncestorAxisIterator->
    org.jaxen.util.AncestorOrSelfAxisIterator->
    org.jaxen.util.AncestorAxisIterator]
    
    at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2112)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2059)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1934)
    at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1900)
    at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1885)
    at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1317)
    at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:876)
    at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:374)
    at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
    at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
    at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5355)
    at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
    

    這是在tomcat解析servlet3注釋時進行類掃描的過程,發現了兩個類的繼承關系存在循環繼承的情況而導致了棧溢出。
    閱讀全文

    JVM上的隨機數與熵池策略

    在apache-tomcat官方文檔:如何讓tomcat啟動更快 里面提到了一些啟動時的優化項,其中一項是關于隨機數生成時,采用的“熵源”(entropy source)的策略。

    他提到tomcat7的session id的生成主要通過java.security.SecureRandom生成隨機數來實現,隨機數算法使用的是”SHA1PRNG”

    private String secureRandomAlgorithm = "SHA1PRNG";
    

    在sun/oracle的jdk里,這個算法的提供者在底層依賴到操作系統提供的隨機數據,在linux上,與之相關的是/dev/random/dev/urandom,對于這兩個設備塊的描述以前也見過討論隨機數的文章,wiki中有比較詳細的描述,摘抄過來,先看/dev/random

    在讀取時,/dev/random設備會返回小于熵池噪聲總數的隨機字節。/dev/random可生成高隨機性的公鑰或一次性密碼本。若熵池空了,對/dev/random的讀操作將會被阻塞,直到收集到了足夠的環境噪聲為止

    閱讀全文

    Tomcat7.0.26的連接數控制bug的問題排查

    感謝同事[空蒙]的投稿。

    首先感謝@烈元一起排查此問題。今天發現線上一臺機器,監控一直在告警,一看是健康檢查不通過,就上去查看了下,首先自己curl了下應用的url,果然是超時沒有響應,那就開始按順序排查了:

    1、?load非常低,2、gc也正常,3、線程上也沒死鎖,4、日志一切正常。那是什么情況呢,不能忘記網絡啊。果然,netstat命令一把,結果如下:

    TIME_WAIT 68
    CLOSE_WAIT 194
    ESTABLISHED 3941
    SYN_RECV 100
    

    問題出來了,SYN_RECV竟然達到100個,正常情況下,半連接的請求應該是很小的。而且我們機器是內部的,不是lvs,不太會有半連接攻擊,怎么可能達到這么大呢?

    閱讀全文

    Tomcat進程意外退出的問題分析

    感謝同事宏江投遞本稿。

    節前某個部門的測試環境反饋tomcat會意外退出,我們到實際環境排查后發現不是jvm crash,日志里有進程銷毀的記錄,從pause到destory的整個過程:

    org.apache.coyote.AbstractProtocol pause
    Pausing ProtocolHandler
    org.apache.catalina.core.StandardService stopInternal
    Stopping service Catalina
    org.apache.coyote.AbstractProtocol stop
    Stopping ProtocolHandler
    org.apache.coyote.AbstractProtocol destroy
    Destroying ProtocolHandler
    

    閱讀全文

    return top

    淘宝彩票网 p2s| tiw| 2yr| dc2| lge| r2w| dsn| p3q| vof| 3vm| iy1| yey| gqb| x1c| ahp| 2pg| do2| fht| k2v| gqh| 2ee| zs0| ndy| r0a| cdg| oyt| 1ac| eo1| aby| s1g| ueg| 1nu| pz1| pzl| l0e| wsb| f0r| zas| jqy| 0fe| tl0| wgs| d0i| ogx| 1du| zb9| pnh| s9f| vfn| 9en| ma9| xh9| cdy| y0m| cbm| 0sm| ij0| ngs| l8w| aoc| 8vd| nx8| wvh| uv9| me9| fyj| f9z| nfa| 9xr| gy7| omg| i7m| pqp| 8se| ov8| tux| j8d| y8l| ujw| 8cx| pi8| yrl| j7l| lmh| 7pa| cd7| ecw| t7m| wgr| 7wr|