spring定时任务执行两次及tomcat部署缓慢问题的解决方法

spring定时任务执行两次及tomcat部署缓慢问题的解决方法

一、spring定时任务执行两次

问题重现和解析

最近使用quartz定时任务框架，结果发现开发环境执行无任何问题，部署到服务器上后，发现同一时间任务执行了多次。经过搜索发现是服务器上tomcat的配置文件出现了问题。

原来的配置文件——server.xml如下：

prefix="localhost_access_log" suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

一个Host表示一个容器，里面可以包含若干个Context（应用）。上面这段配置文件意思就是：在tomcat中配置了两个容器，一个name=localhost，应用的根目录为webapps，并且会自动解压war包和自动部署。没有指定context，会把根目录下的所有web应用都部署，部署成功后，外网可以通过服务器IP+项目名来访问；另一个name=xxx.com，和第一个host不同在于，配置了主页web应用，且不需要跟项目名就可以访问。部署成功后可以通过域名+项目名访问，主页所在项目可以直接通过根域名访问。

这个时候问题就来了，包含定时任务的项目部署在webapps目录下，tomcat中两个独立的容器都部署了一遍，相当于项目在服务器上的tomcat上部署了两次，两边同时会运行定时任务，指定的是同一个数据库。

问题解决

因此，为了尽可能不影响其他项目的正常访问，我做了折中，讲需要执行定时任务的项目单独部署在另一个文件夹中，例如webroot ，然后只使用域名那个host，配置文件修改后如下：

prefix="localhost_access_log" suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

</Host>

可以看到projectC是包含定时任务的项目。这样部署成功后，除了该项目只能通过域名访问之外，其余项目的访问方式和之前保持不变。同时问题解决，定时任务只执行一次。

网上的另一种说法

只有一个host，tomcat在启动时，会部署一次根目录下的所有项目，然后Context又会单独部署一次，所以也会导致定时任务执行2次。

对于这种问题，解决的方案也有多种：

将huost的appBase设为空，将Context的Context 指向项目部署位置的绝对路径。

删除Context节点。

二、tomcat部署缓慢的问题

用的阿里云服务器，部署tomcat时速度非常慢，但是后来买的新阿里云又没有这个问题。部署项目后一直会在

INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /opt/apache-tomcat-8.0.15-server/webapps/ROOT

这里卡好几分钟才会继续下去。之前一直以为是服务器配置原因，后来无意中发现是jre的配置原因。参考了几篇博客，发现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 http://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上产生随机数的策略有两种：/dev/random 和/dev/urandom。

tomcat或者WebLogic等web服务器在部署时需要等待若一段随机数产生的时间。unix平台下JVM默认采用的是安全性更好的/dev/random，但是潜在的会阻塞服务进程。

推荐使用/dev/urandom，产生随机数速度快，/dev/random需要时间间隔生成随机数，部署时间长。

修改方式：

打开$java_HOME/jre/lib/security/java.security文件。

将securerandom.source=file:/dev/random 修改为securerandom.source=file:/dev/urandom

重启tomcat，三十秒部署成功，solve it

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我们的支持。

prefix="localhost_access_log" suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

一个Host表示一个容器，里面可以包含若干个Context（应用）。上面这段配置文件意思就是：在tomcat中配置了两个容器，一个name=localhost，应用的根目录为webapps，并且会自动解压war包和自动部署。没有指定context，会把根目录下的所有web应用都部署，部署成功后，外网可以通过服务器IP+项目名来访问；另一个name=xxx.com，和第一个host不同在于，配置了主页web应用，且不需要跟项目名就可以访问。部署成功后可以通过域名+项目名访问，主页所在项目可以直接通过根域名访问。

这个时候问题就来了，包含定时任务的项目部署在webapps目录下，tomcat中两个独立的容器都部署了一遍，相当于项目在服务器上的tomcat上部署了两次，两边同时会运行定时任务，指定的是同一个数据库。

问题解决

因此，为了尽可能不影响其他项目的正常访问，我做了折中，讲需要执行定时任务的项目单独部署在另一个文件夹中，例如webroot ，然后只使用域名那个host，配置文件修改后如下：

prefix="localhost_access_log" suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

</Host>

可以看到projectC是包含定时任务的项目。这样部署成功后，除了该项目只能通过域名访问之外，其余项目的访问方式和之前保持不变。同时问题解决，定时任务只执行一次。

网上的另一种说法

只有一个host，tomcat在启动时，会部署一次根目录下的所有项目，然后Context又会单独部署一次，所以也会导致定时任务执行2次。

对于这种问题，解决的方案也有多种：

将huost的appBase设为空，将Context的Context 指向项目部署位置的绝对路径。

删除Context节点。

二、tomcat部署缓慢的问题

用的阿里云服务器，部署tomcat时速度非常慢，但是后来买的新阿里云又没有这个问题。部署项目后一直会在

INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /opt/apache-tomcat-8.0.15-server/webapps/ROOT

这里卡好几分钟才会继续下去。之前一直以为是服务器配置原因，后来无意中发现是jre的配置原因。参考了几篇博客，发现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 http://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上产生随机数的策略有两种：/dev/random 和/dev/urandom。

tomcat或者WebLogic等web服务器在部署时需要等待若一段随机数产生的时间。unix平台下JVM默认采用的是安全性更好的/dev/random，但是潜在的会阻塞服务进程。

推荐使用/dev/urandom，产生随机数速度快，/dev/random需要时间间隔生成随机数，部署时间长。

修改方式：

打开$java_HOME/jre/lib/security/java.security文件。

将securerandom.source=file:/dev/random 修改为securerandom.source=file:/dev/urandom

重启tomcat，三十秒部署成功，solve it

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我们的支持。

prefix="localhost_access_log" suffix=".txt"

pattern="%h %l %u %t "%r" %s %b" />

</Host>

可以看到projectC是包含定时任务的项目。这样部署成功后，除了该项目只能通过域名访问之外，其余项目的访问方式和之前保持不变。同时问题解决，定时任务只执行一次。

网上的另一种说法

只有一个host，tomcat在启动时，会部署一次根目录下的所有项目，然后Context又会单独部署一次，所以也会导致定时任务执行2次。

对于这种问题，解决的方案也有多种：

将huost的appBase设为空，将Context的Context 指向项目部署位置的绝对路径。

删除Context节点。

二、tomcat部署缓慢的问题

用的阿里云服务器，部署tomcat时速度非常慢，但是后来买的新阿里云又没有这个问题。部署项目后一直会在

INFO [localhost-startStop-1] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory /opt/apache-tomcat-8.0.15-server/webapps/ROOT

这里卡好几分钟才会继续下去。之前一直以为是服务器配置原因，后来无意中发现是jre的配置原因。参考了几篇博客，发现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 http://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上产生随机数的策略有两种：/dev/random 和/dev/urandom。

tomcat或者WebLogic等web服务器在部署时需要等待若一段随机数产生的时间。unix平台下JVM默认采用的是安全性更好的/dev/random，但是潜在的会阻塞服务进程。

推荐使用/dev/urandom，产生随机数速度快，/dev/random需要时间间隔生成随机数，部署时间长。

修改方式：

打开$java_HOME/jre/lib/security/java.security文件。

将securerandom.source=file:/dev/random 修改为securerandom.source=file:/dev/urandom

重启tomcat，三十秒部署成功，solve it

总结

以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，如果有疑问大家可以留言交流，谢谢大家对我们的支持。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。