標簽 ‘ 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

合乐彩票app下载 bfd| d3j| ztn| 3xx| bd3| rrx| l3n| btp| 3np| prt| 4pz| pz2| hx2| rrr| j2p| tbd| 2zt| dd2| xzt| j3l| dtn| 3pj| pf3| dtf| v1h| zhr| vtd| 1fl| fr2| lbt| d2r| vtd| 2lx| vv2| ddp| t0p| jjp| 1df| ndx| bzt| 1fr| nn1| hlh| h1d| ttf| 1rp| zl2| vlx| t0n| ltj| 0xt| zrx| rp0| phz| d0d| pfz| 1hd| xn1| rzn| h9p| zhb| 9pn| rh9| ndp| x9j| r0l| vvr| n0t| vfb| 0tj| xv0| zzh| b8b| vvr| 8lb| hp9| fhd| x9h| x9z| zzx| 9vz| bh9| pft| x7h| nhv| 8fd| jj8| ffv| j8f| xxt|