1. Les tâches chronométrées à ressort sont exécutées deux fois
Problème de reproduction et d'analyse
Récemment, j'ai utilisé le cadre de tâche de synchronisation quartz et j'ai constaté qu'il n'y avait aucun problème avec l'exécution de l'environnement de développement. Après l'avoir déployé sur le serveur, j'ai constaté que la tâche avait été exécutée plusieurs fois en même temps. Après la recherche, j'ai constaté qu'il y avait un problème avec le fichier de configuration Tomcat sur le serveur.
Le fichier de configuration d'origine - Server.xml est le suivant:
<Host name = "localhost" Appbase = "webApps" DebackWars = "true" autodePloy = "true"> <valve classname = "org.apache.catalina.valves.accessLogValve" Directory = "Logs" préfix = "localhost_access_log" /> </ Host> <host name = "www.xxx.com" appbase = "webapps" unpackwars = "true" autodeploy = "true" xmlvalidation = "false" xmlNamespaceaware = "false"> < rechargernable = "true"> </ context> </host>
Un hôte représente un conteneur qui peut contenir plusieurs contextes (applications). Le fichier de configuration ci-dessus signifie: deux conteneurs sont configurés dans TomCat, One Name = LocalHost, le répertoire racine de l'application est WebApps et le package de guerre sera automatiquement décompressé et déployé automatiquement. Si le contexte n'est pas spécifié, toutes les applications Web du répertoire racine seront déployées. Une fois le déploiement réussi, le réseau externe est accessible via le nom du projet IP + Server; L'autre nom = www.xxx.com, qui est différent du premier hôte, est configuré avec l'application Web de la page d'accueil et n'a pas besoin d'être accessible avec le nom du projet. Une fois le déploiement réussi, vous pouvez y accéder via le nom de domaine + nom du projet, et le projet où la page d'accueil est située est accessible directement via le nom de domaine racine.
Pour le moment, le problème se pose. Le projet contenant les tâches de synchronisation est déployé dans le répertoire WebApps. Deux conteneurs indépendants de Tomcat sont déployés une fois, ce qui équivaut au projet déployé deux fois sur Tomcat sur le serveur. Les deux côtés exécuteront les tâches de synchronisation en même temps et la même base de données est spécifiée.
Résolution de problèmes
Par conséquent, afin de ne pas affecter autant que possible l'accès normal des autres projets, j'ai fait un compromis et j'ai dit que le projet qui doit effectuer des tâches de synchronisation est déployé séparément dans un autre dossier, tel que webroot, puis utiliser uniquement l'hôte de nom de domaine. Une fois le fichier de configuration modifié, ce qui suit est le suivant:
<Host name = "localhost" Appbase = "webApps" DebackWars = "true" autodePloy = "true"> <valve classname = "org.apache.catalina.valves.accessLogValve" Directory = "Logs" préfix = "localhost_access_log" /> </ Host> <host name = "www.xxx.com" appbase = "" unbackwars = "true" autodeploy = "true" xmlvalidation = "false" xmlNamespaceaware = "false"> < rechargeable = "true"> </ context> < rechargeryable = "true"> </ context> <
Vous pouvez voir que ProjectC est un projet contenant des tâches de synchronisation. Après un déploiement réussi, à l'exception du projet qui ne peut être accessible que via le nom de domaine, la méthode d'accès des autres projets reste inchangée avant. Dans le même temps, le problème est résolu et la tâche de synchronisation n'est exécutée qu'une seule fois.
Un autre dicton en ligne
<Host name = "localhost" Appbase = "webApps" DebackWars = "True" AutodePloy = "true"> <
Il n'y a qu'un seul hôte. Lorsque Tomcat est démarré, tous les projets du répertoire racine seront déployés une fois, puis le contexte sera à nouveau déployé, ce qui entraînera également l'exécution de la tâche de synchronisation deux fois.
Il existe de nombreuses solutions à ce problème:
2. Le problème du déploiement lent Tomcat
Le serveur Cloud Alibaba que j'ai utilisé était très lent lors du déploiement de Tomcat, mais le nouveau cloud Alibaba que j'ai acheté plus tard n'a pas eu ce problème. Une fois le projet déployé, il sera
Info [localhost-startstop-1] org.apache.catalina.startup.hostconfig.deploydirectory déploiement du répertoire d'application Web /opt/apache-tomcat-8.0.15-server/webapps/root
Il faut plusieurs minutes pour continuer ici. J'avais l'habitude de penser que c'était la raison de la configuration du serveur, mais plus tard, j'ai découvert accidentellement que c'était la raison de la configuration JRE. Après avoir fait référence à plusieurs blogs, j'ai constaté qu'Oracle a donné des raisons et des solutions sous la documentation de WebLogic.
La bibliothèque utilisée pour la génération de nombres aléatoires dans JVM de Sun s'appuie sur / dev / aléatoire par défaut pour les plates-formes UNIX. Cela peut potentiellement bloquer le processus de serveur SIP Weblogic, car sur certains systèmes d'exploitation / DEV / aléatoires attend une certaine quantité de "bruit" à générer sur la machine hôte avant de renvoyer un résultat. Bien que / dev / aléatoire soit plus sécurisé, BEA recommande d'utiliser / dev / urandom si la configuration JVM par défaut retarde le démarrage du serveur SIP WebLogic SIP.
Signification:
Méthode de modification:
Résumer
Ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article a une certaine valeur de référence pour l'étude ou le travail de chacun. Si vous avez des questions, vous pouvez laisser un message pour communiquer. Merci pour votre soutien à wulin.com.