1. Las tareas cronometradas de primavera se ejecutan dos veces
Problema de reproducción y análisis
Recientemente, utilicé el marco de tareas de tiempo de cuarzo y descubrí que no había ningún problema con la ejecución del entorno de desarrollo. Después de implementarlo en el servidor, descubrí que la tarea se ejecutó varias veces al mismo tiempo. Después de buscar, descubrí que había un problema con el archivo de configuración de Tomcat en el servidor.
El archivo de configuración original - Server.xml es el siguiente:
<Host name = "localhost" appbase = "webapps" impackwars = "true" autodePloy = "true"> <valve classname = "org.apache.catalina.valves.accesslogvalve" directorio = "logs" prefix = "localhost_access_log" sufrex = ". Txt" patrones = " % %l %l %t %s %s %sming" /> </Host> <host name = "www.xxx.com" appbase = "webapps" impackwars = "true" autodePloy = "true" xmlvalidation = "false" xmlnamespaceaware = "false"> <context) reloadable = "true"> </textis> </gest>
Un host representa un contenedor que puede contener varios contextos (aplicaciones). El archivo de configuración anterior significa: dos contenedores están configurados en TomCat, un nombre = localhost, el directorio raíz de la aplicación es webapps y el paquete de guerra se descomprimará e implementará automáticamente automáticamente. Si no se especifica el contexto, se implementarán todas las aplicaciones web en el directorio raíz. Una vez que la implementación es exitosa, se puede acceder a la red externa a través del nombre del proyecto IP + del servidor; El otro nombre = www.xxx.com, que es diferente del primer host, está configurado con la aplicación web de la página de inicio y no es necesario acceder con el nombre del proyecto. Después de que la implementación sea exitosa, puede acceder a ella a través del nombre de dominio + el nombre del proyecto, y se puede acceder directamente al proyecto donde se encuentra la página de inicio a través del nombre de dominio raíz.
En este momento, surge el problema. El proyecto que contiene las tareas de tiempo se implementa en el directorio webApps. Dos contenedores independientes en Tomcat se implementan una vez, lo cual es equivalente al proyecto que se implementa dos veces en Tomcat en el servidor. Ambas partes ejecutarán tareas de tiempo al mismo tiempo, y se especifica la misma base de datos.
Resolución de problemas
Por lo tanto, para no afectar el acceso normal de otros proyectos tanto como sea posible, hice un compromiso y dije que el proyecto que necesita realizar tareas de tiempo se implementa por separado en otra carpeta, como Webroot, y luego solo usa el host de nombre de dominio. Después de modificar el archivo de configuración, el siguiente es el siguiente:
<Host name = "localhost" appbase = "webapps" impackwars = "true" autodePloy = "true"> <valve classname = "org.apache.catalina.valves.accesslogvalve" directorio = "logs" prefix = "localhost_access_log" sufrex = ". Txt" patrones = " % %l %l %t %s %s %sming" /> </Host> <host name = "www.xxx.com" appbase = "" impackwars = "true" autodePloy = "true" xmlvalidation = "false" xmlnamespaceaware = "false"> <context = "" DocBase = "/usr/local/tomcat/apache-tomcat-8.5.9/webapps/xxxx" reloadable = "true"> </context> <context) reloadable = "true"> </textil> <context)
Puede ver que ProjectC es un proyecto que contiene tareas de tiempo. Después de una implementación exitosa, a excepción del proyecto al que solo se puede acceder a través del nombre de dominio, el método de acceso de los otros proyectos permanece sin cambios desde antes. Al mismo tiempo, el problema se resuelve y la tarea de sincronización solo se ejecuta una vez.
Otro dicho en línea
<Host name = "localhost" appbase = "webapps" impackwars = "true" autodePloy = "true"> <context docbase = "proyectA" path = "" reloadable = "true" /> < /host>
Solo hay un anfitrión. Cuando se inicia Tomcat, todos los proyectos en el directorio raíz se implementarán una vez, y luego el contexto se implementará una vez más, lo que también hará que la tarea de tiempo se ejecute dos veces.
Hay muchas soluciones a este problema:
2. El problema del despliegue lento de Tomcat
El servidor de la nube Alibaba que utilicé fue muy lento al implementar Tomcat, pero la nueva nube de Alibaba que compré más tarde no tenía este problema. Después de implementar el proyecto, será
Información [localhost-startstop-1] org.apache.catalina.startup.hostconfig.deploydirectory implementando directorio de aplicaciones web /opt/apache-toMcat-8.0.15-server/webapps/root
Se necesitan varios minutos para continuar aquí. Solía pensar que era la razón de configuración del servidor, pero luego descubrí accidentalmente que era la razón de configuración JRE. Después de referirme a varios blogs, descubrí que Oracle daba razones y soluciones bajo la documentación de WebLogic.
La biblioteca utilizada para la generación de números aleatorios en JVM de Sun se basa en /dev /Random de forma predeterminada para plataformas UNIX. Esto puede bloquear el proceso de servidor SIP WebLogic porque en algunos sistemas operativos /dev /aleatorios esperan que se genere una cierta cantidad de "ruido" en la máquina host antes de devolver un resultado. Aunque /dev /Random es más seguro, BEA recomienda usar /dev /urandom si la configuración JVM predeterminada retrasa el inicio del servidor SIP WebLogic.
Significado:
Método de modificación:
Resumir
Lo anterior es todo el contenido de este artículo. Espero que el contenido de este artículo tenga cierto valor de referencia para el estudio o el trabajo de todos. Si tiene alguna pregunta, puede dejar un mensaje para comunicarse. Gracias por su apoyo a Wulin.com.