問題重現(xiàn)和解析
最近使用quartz定時任務(wù)框架,結(jié)果發(fā)現(xiàn)開發(fā)環(huán)境執(zhí)行無任何問題,部署到服務(wù)器上后,發(fā)現(xiàn)同一時間任務(wù)執(zhí)行了多次。經(jīng)過搜索發(fā)現(xiàn)是服務(wù)器上tomcat的配置文件出現(xiàn)了問題。
原來的配置文件——server.xml如下:
1
2
3
4
5
6
7
8
|
<Host name= "localhost" appBase= "webapps" unpackWARs= "true" autoDeploy= "true" > <Valve className= "org.apache.catalina.valves.AccessLogValve" directory= "logs" prefix= "localhost_access_log" suffix= ".txt" pattern= "%h %l %u %t "%r" %s %b" /> </Host> <Host name= "www.xxx.com" appBase= "webapps" unpackWARs= "true" autoDeploy= "true" xmlValidation= "false" xmlNamespaceAware= "false" > <Context path= "" docBase= "/usr/local/tomcat/apache-tomcat-8.5.9/webapps/xxxindex" reloadable= "true" ></Context> </Host> |
一個Host表示一個容器,里面可以包含若干個Context(應(yīng)用)。上面這段配置文件意思就是:在tomcat中配置了兩個容器,一個name=localhost,應(yīng)用的根目錄為webapps,并且會自動解壓war包和自動部署。沒有指定context,會把根目錄下的所有web應(yīng)用都部署,部署成功后,外網(wǎng)可以通過服務(wù)器IP+項目名來訪問;另一個name=www.xxx.com,和第一個host不同在于,配置了主頁web應(yīng)用,且不需要跟項目名就可以訪問。部署成功后可以通過域名+項目名訪問,主頁所在項目可以直接通過根域名訪問。
這個時候問題就來了,包含定時任務(wù)的項目部署在webapps目錄下,tomcat中兩個獨立的容器都部署了一遍,相當(dāng)于項目在服務(wù)器上的tomcat上部署了兩次,兩邊同時會運行定時任務(wù),指定的是同一個數(shù)據(jù)庫。
問題解決
因此,為了盡可能不影響其他項目的正常訪問,我做了折中,講需要執(zhí)行定時任務(wù)的項目單獨部署在另一個文件夾中,例如webroot ,然后只使用域名那個host,配置文件修改后如下:
1
2
3
4
5
6
7
8
9
10
11
|
<Host name= "localhost" appBase= "webapps" unpackWARs= "true" autoDeploy= "true" > <Valve className= "org.apache.catalina.valves.AccessLogValve" directory= "logs" prefix= "localhost_access_log" suffix= ".txt" pattern= "%h %l %u %t "%r" %s %b" /> </Host> <Host name= "www.xxx.com" appBase= "" unpackWARs= "true" autoDeploy= "true" xmlValidation= "false" xmlNamespaceAware= "false" > <Context path= "" docBase= "/usr/local/tomcat/apache-tomcat-8.5.9/webapps/xxxindex" reloadable= "true" ></Context> <Context path= "/projectA" docBase= "/usr/local/tomcat/apache-tomcat-8.5.9/webapps/projectA" reloadable= "true" ></Context> <Context path= "/projectB" docBase= "/usr/local/tomcat/apache-tomcat-8.5.9/webapps/projectB" reloadable= "true" ></Context> <Context path= "/projectC" docBase= "/usr/local/tomcat/apache-tomcat-8.5.9/webroot/projectC" reloadable= "true" ></Context> </Host> |
可以看到projectC是包含定時任務(wù)的項目。這樣部署成功后,除了該項目只能通過域名訪問之外,其余項目的訪問方式和之前保持不變。同時問題解決,定時任務(wù)只執(zhí)行一次。
網(wǎng)上的另一種說法
1
2
3
|
<Host name= "localhost" appBase= "webapps" unpackWARs= "true" autoDeploy= "true" > <Context docBase= "projectA" path= "" reloadable= "true" /> </Host> |
只有一個host,tomcat在啟動時,會部署一次根目錄下的所有項目,然后Context又會單獨部署一次,所以也會導(dǎo)致定時任務(wù)執(zhí)行2次。
對于這種問題,解決的方案也有多種:
- 將huost的appBase設(shè)為空,將Context的Context 指向項目部署位置的絕對路徑。
- 刪除Context節(jié)點。
二、tomcat部署緩慢的問題
用的阿里云服務(wù)器,部署tomcat時速度非常慢,但是后來買的新阿里云又沒有這個問題。部署項目后一直會在
INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /opt/apache-tomcat-8.0.15-server/webapps/ROOT
這里卡好幾分鐘才會繼續(xù)下去。之前一直以為是服務(wù)器配置原因,后來無意中發(fā)現(xiàn)是jre的配置原因。參考了幾篇博客,發(fā)現(xiàn)oracle在WebLogic的文檔下Avoiding JVM Delays Caused by Random Number Generation給了原因和解決方案。
The library used for random number generation in Sun's JVM relies on /dev/random by default for UNIX platforms. This can potentially block the WebLogic SIP Server process because on some operating systems /dev/random waits for a certain amount of "noise" to be generated on the host machine before returning a result. Although /dev/random is more secure, BEA recommends using /dev/urandom if the default JVM configuration delays WebLogic SIP Server startup.
意思就是:
- JVM上產(chǎn)生隨機數(shù)的策略有兩種:/dev/random 和/dev/urandom。
- tomcat或者WebLogic等web服務(wù)器在部署時需要等待若一段隨機數(shù)產(chǎn)生的時間。unix平臺下JVM默認采用的是安全性更好的/dev/random,但是潛在的會阻塞服務(wù)進程。
- 推薦使用/dev/urandom,產(chǎn)生隨機數(shù)速度快,/dev/random需要時間間隔生成隨機數(shù),部署時間長。
修改方式:
- 打開$JAVA_HOME/jre/lib/security/java.security文件。
- 將securerandom.source=file:/dev/random 修改為securerandom.source=file:/dev/urandom
- 重啟tomcat,三十秒部署成功,solve it
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,如果有疑問大家可以留言交流,謝謝大家對服務(wù)器之家的支持。
原文鏈接:https://www.cnblogs.com/Sinte-Beuve/p/8360321.html