1. يتم تنفيذ المهام الموقوتة الربيعية مرتين
مشكلة إعادة التوزيع والتحليل
في الآونة الأخيرة ، استخدمت إطار مهمة توقيت الكوارتز ووجدت أنه لا توجد مشكلة في تنفيذ بيئة التطوير. بعد نشره على الخادم ، وجدت أن المهمة قد تم تنفيذها عدة مرات في نفس الوقت. بعد البحث ، وجدت أن هناك مشكلة في ملف تكوين Tomcat على الخادم.
ملف التكوين الأصلي - server.xml كما يلي:
<host name = "localHost" appBase = "WebApps" unpackWars = "true" autodeploy = "true"> <valve className = "org.apache.catalina.valves.AccessLogval" directory = "logs" prefix = "localhost_Access_LOG" fudge = txt ". /> </sode> <name name = "www.xxx.com" appbase = "webapps" unpackwars = "true" autodeploy = "true" RELOADABLE = "true"> </sectext> </sold>
يمثل المضيف حاوية يمكن أن تحتوي على عدة سياقات (التطبيقات). يعني ملف التكوين أعلاه: يتم تكوين حاوية في tomcat ، اسم واحد = LocalHost ، الدليل الجذر للتطبيق هو WebApps ، وسيتم إلغاء ضغط حزمة الحرب تلقائيًا ونشرها تلقائيًا. إذا لم يتم تحديد السياق ، فسيتم نشر جميع تطبيقات الويب في دليل الجذر. بعد نجاح النشر ، يمكن الوصول إلى الشبكة الخارجية من خلال اسم مشروع الخادم IP + ؛ تم تكوين الاسم الآخر = www.xxx.com ، الذي يختلف عن المضيف الأول ، مع تطبيق الويب للصفحة الرئيسية ولا يلزم الوصول إليه باسم المشروع. بعد نجاح النشر ، يمكنك الوصول إليه من خلال اسم المجال + اسم المشروع ، ويمكن الوصول إلى المشروع الذي توجد فيه الصفحة الرئيسية مباشرة من خلال اسم مجال الجذر.
في هذا الوقت ، تنشأ المشكلة. يتم نشر المشروع الذي يحتوي على مهام التوقيت في دليل WebApps. يتم نشر حاويتين مستقلتين في Tomcat مرة واحدة ، وهو ما يعادل المشروع الذي يتم نشره مرتين على Tomcat على الخادم. سيقوم كلا الجانبين بتشغيل مهام التوقيت في نفس الوقت ، ويتم تحديد نفس قاعدة البيانات.
حل المشكلات
لذلك ، لكي لا تؤثر على الوصول الطبيعي للمشاريع الأخرى قدر الإمكان ، قدمت حل وسط ، وقالت إن المشروع الذي يحتاج إلى أداء مهام التوقيت يتم نشره بشكل منفصل في مجلد آخر ، مثل Webroot ، ثم استخدام مضيف اسم المجال فقط. بعد تعديل ملف التكوين ، فإن ما يلي كما يلي:
<host name = "localHost" appBase = "WebApps" unpackWars = "true" autodeploy = "true"> <valve className = "org.apache.catalina.valves.AccessLogval" directory = "logs" prefix = "localhost_Access_LOG" fudge = txt ". /> </soft> <name name = "www.xxx.com" appbase = "" unpackwars = "true" autodeploy = "true" RELOADABLE = "true"> </context> <context path = "/projecta" docBase = "/usr/tomcat/apache-tomcat-8.5.9/webapps/projecta" reloadable = "true"> </context> RELOADABLE = "true"> </sectext> <context path = "/projectc" docBase = "/usr/tomcat/apache-tomcat-8.5.9/webroot/projectC" reloadable = "true"> </context> </sold>
يمكنك أن ترى أن ProjectC هو مشروع يحتوي على مهام التوقيت. بعد النشر الناجح ، باستثناء المشروع الذي لا يمكن الوصول إليه إلا من خلال اسم المجال ، تظل طريقة الوصول إلى المشاريع الأخرى دون تغيير من قبل. في الوقت نفسه ، يتم حل المشكلة ، ويتم تنفيذ مهمة التوقيت مرة واحدة فقط.
قول آخر عبر الإنترنت
<host name = "localhost" appbase = "webapps" unpackwars = "true" autodeploy = "true"> <context docbase = "projecta" path = "" reloadable = "true" /> </soved>
لا يوجد سوى مضيف واحد. عند بدء تشغيل Tomcat ، سيتم نشر جميع المشاريع في دليل الجذر مرة واحدة ، ثم سيتم نشر السياق مرة أخرى ، مما سيؤدي أيضًا إلى تنفيذ مهمة التوقيت مرتين.
هناك العديد من الحلول لهذه المشكلة:
2. مشكلة نشر تومات البطيئة
كان خادم Alibaba Cloud الذي استخدمته بطيئًا جدًا عند نشر Tomcat ، لكن سحابة Alibaba الجديدة التي اشتريتها لاحقًا لم تواجه هذه المشكلة. بعد نشر المشروع ، سيكون ذلك
info [localhost-startstop-1] org.apache.catalina.startup.hostconfig.deploydirectory directory directory /opt/apache-tomcat-8.0.15-server/webapps/root/root
يستغرق الأمر عدة دقائق للاستمرار هنا. اعتدت أن أعتقد أنه كان سبب تكوين الخادم ، لكن في وقت لاحق اكتشفت بطريق الخطأ أنه سبب تكوين JRE. بعد الإشارة إلى العديد من المدونات ، وجدت أن Oracle أعطت أسبابًا وحلولًا تحت وثائق WebLogic.
تعتمد المكتبة المستخدمة لتوليد الأرقام العشوائية في Sun's JVM على /dev /عشوائي افتراضيًا لمنصات UNIX. يمكن أن يحظر هذا عملية خادم SIP WebLogic لأنه في بعض أنظمة التشغيل /dev /عشوائي ينتظر كمية معينة من "الضوضاء" التي يتم إنشاؤها على جهاز المضيف قبل إرجاع النتيجة. على الرغم من أن /dev /Random أكثر أمانًا ، فإن BEA توصي باستخدام /dev /urandom إذا كان تكوين JVM الافتراضي يؤخر بدء تشغيل خادم WebLogic SIP.
معنى:
طريقة التعديل:
لخص
ما سبق هو المحتوى الكامل لهذه المقالة. آمل أن يكون لمحتوى هذه المقالة قيمة مرجعية معينة لدراسة أو عمل الجميع. إذا كان لديك أي أسئلة ، فيمكنك ترك رسالة للتواصل. شكرا لك على دعمك إلى wulin.com.