एजेपी (mod_jk) का उपयोग करके जेबीओएसएस के साथ अपाचे थ्रेड गिनती

Question

में स्पाइक्स देकर हमने हमारे आवेदन को होस्ट करने के लिए जेबीएसएस के साथ अपाचे का उपयोग किया, लेकिन हमें mod_jk के थ्रेड हैंडलिंग से संबंधित कुछ समस्याएं मिलीं।

हमारी वेबसाइट कम यातायात वेबसाइटों के अंतर्गत आती है और हमारी वेबसाइट के शीर्ष गतिविधि समय के दौरान अधिकतम 200-300 समवर्ती उपयोगकर्ता हैं। जैसे ही यातायात बढ़ता है (समवर्ती उपयोगकर्ताओं के संदर्भ में नहीं, बल्कि हमारे सर्वर पर संचयी अनुरोधों के संदर्भ में), सर्वर ने लंबे समय से अनुरोधों को रोकना बंद कर दिया, हालांकि यह क्रैश नहीं हुआ लेकिन 20 मिनट तक अनुरोध नहीं कर सका। जेबीओएसएस सर्वर कंसोल ने दिखाया कि 350 थ्रेड दोनों सर्वरों पर व्यस्त थे हालांकि पर्याप्त फ्री मेमोरी कहती थी, 1-1.5 जीबी से अधिक (जेबीओएसएस के लिए 2 सर्वर का इस्तेमाल किया गया था जो 64 बिट्स थे, जेबीएसएसएसएस के लिए आवंटित 4 जीबी रैम)

समस्या की जांच करने के लिए हम जेबीओएसएस और अपाचे वेब कंसोल का उपयोग कर रहे थे, और हम देख रहे थे कि धागा एस राज्य में मिनटों तक दिखा रहा था, हालांकि हमारे पृष्ठों को 4-5 सेकेंड तक सेवा दी जाती है।

हमने थ्रेड डंप लिया और पाया कि थ्रेड ज्यादातर राज्य में थे जिसका मतलब है कि वे अनिश्चित काल तक इंतजार कर रहे थे। ये धागे हमारे आवेदन वर्गों में नहीं बल्कि एजेपी 800 9 बंदरगाह के थे।

क्या कोई इस में मेरी सहायता कर सकता है, क्योंकि किसी और को भी यह समस्या मिल सकती है और इसे किसी भी तरह हल किया जा सकता है। यदि किसी और जानकारी की आवश्यकता है तो मुझे बताएं।

mod_prok का उपयोग करने से भी mod_proxy बेहतर है, या mod_proxy के साथ कुछ अन्य समस्याएं हैं जो मेरे लिए घातक हो सकती हैं यदि मैं mod__proxy पर स्विच करता हूं?

Apache 2.0.52 
JBOSS: 4.2.2 
MOD_JK: 1.2.20 
JDK: 1.6 
Operating System: RHEL 4 

मदद के लिए धन्यवाद:

संस्करणों मैं इस्तेमाल किया इस प्रकार हैं।

दोस्तों !!!! हमने अंत में ऊपर उल्लिखित कॉन्फ़िगरेशन के साथ कामकाज पाया। यह एपीआर का उपयोग है और यहां उल्लेख किया गया है: http://community.jboss.org/thread/153737। नीचे दिए गए उत्तरों में कई लोगों द्वारा सही ढंग से उल्लिखित मुद्दा यह है कि कनेक्टर समस्या। इससे पहले हमने हाइबरनेट को कॉन्फ़िगर करके और प्रतिक्रिया समय में वृद्धि करके अस्थायी कार्यवाही की। पूर्ण फिक्स एपीआर है।

Answer 1

हम इसी तरह के मुद्दों का सामना कर रहे हैं। हम अभी भी समाधान पर काम कर रहे हैं, लेकिन यह यहां पाया जा सकता उत्तरों की बहुत की तरह लग रहा:

http://www.jboss.org/community/wiki/OptimalModjk12Configuration

गुड लक!

Answer 2

तुम भी JBoss Jira मुद्दे पर एक नज़र, जिसका शीर्षक "CLOSE_WAIT स्थिति में AJP कनेक्टर धागे त्रिशंकु" लेना चाहिए:

https://jira.jboss.org/jira/browse/JBPAPP-366

Answer 3

क्या हम इस मुद्दे बाहर छँटाई के लिए किया था इस प्रकार है:

<property name="hibernate.cache.use_second_level_cache">false</property> 


<property name="hibernate.search.default.directory_provider">org.hibernate.search.store.FSDirectoryProvider</property> 
    <property name="hibernate.search.Rules.directory_provider"> 
     org.hibernate.search.store.RAMDirectoryProvider 
    </property> 

    <property name="hibernate.search.default.indexBase">/usr/local/lucene/indexes</property> 

    <property name="hibernate.search.default.indexwriter.batch.max_merge_docs">1000</property> 
    <property name="hibernate.search.default.indexwriter.transaction.max_merge_docs">10</property> 

    <property name="hibernate.search.default.indexwriter.batch.merge_factor">20</property> 
    <property name="hibernate.search.default.indexwriter.transaction.merge_factor">10</property> 

<property name ="hibernate.search.reader.strategy">not-shared</property> 
<property name ="hibernate.search.worker.execution">async</property> 
<property name ="hibernate.search.worker.thread_pool.size">100</property> 
<property name ="hibernate.search.worker.buffer_queue.max">300</property> 

<property name ="hibernate.search.default.optimizer.operation_limit.max">1000</property> 
<property name ="hibernate.search.default.optimizer.transaction_limit.max">100</property> 

<property name ="hibernate.search.indexing_strategy">manual</property> 

उपरोक्त मानकों ने सुनिश्चित किया कि कार्यकर्ता धागे ल्यूसीन और हाइबरनेट खोज द्वारा अवरुद्ध नहीं हैं। हाइबरनेट के डिफ़ॉल्ट अनुकूलक ने हमारे जीवन को आसान बना दिया, इस प्रकार मैं इस सेटिंग को बहुत महत्वपूर्ण मानता हूं।

ने सी 3 पी 0 कनेक्शन पूलिंग को भी हटा दिया और इनबिल्ट जेडीबीसी कनेक्शन पूलिंग का उपयोग किया, इस प्रकार हमने अनुभाग के नीचे टिप्पणी की।

<!--For JDBC connection pool (use the built-in)--> 


<property name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property> 
    <!-- DEPRECATED very expensive property name="c3p0.validate>--> 
    <!-- seconds --> 

यह सब करने के बाद, हम काफी समय जो एक AJP धागा एक अनुरोध सेवा करने के लिए ले जा रही थी को कम करने में सक्षम थे और धागे एस राज्य में अनुरोध अर्थात की सेवा के बाद आर राज्य के लिए आ रहा शुरू कर दिया।

Answer 4

हाल ही में दर्ज किए गए टोमकैट 6 में एक बग है। यह HTTP कनेक्टर के संबंध में है लेकिन लक्षण समान ध्वनि हैं।

https://issues.apache.org/bugzilla/show_bug.cgi?id=48843#c1

Answer 5

हम एक Jboss 5 वातावरण में इस मुद्दे कर रहे थे। कारण एक वेब सेवा थी जिसे जब्स/टोमकैट की अनुमति देने के लिए अधिक समय लगता था। इससे एजेपी थ्रेड पूल अंततः इसके उपलब्ध धागे को समाप्त कर देगा। फिर यह जवाब देना बंद कर देगा। हमारा समाधान अनुरोध/प्रतिक्रिया पैटर्न के बजाय अनुरोध/स्वीकृति पैटर्न का उपयोग करने के लिए वेब सेवा को समायोजित करना था। इसने वेब सेवा को हर समय टाइमआउट अवधि के भीतर जवाब देने की अनुमति दी। अनुमोदित यह Jboss के अंतर्निहित कॉन्फ़िगरेशन समस्या को हल नहीं करता है, लेकिन हमारे संदर्भ में jboss को ट्यून करने से हमारे लिए यह करना आसान था।

Answer 6

अपाचे देशी एपीआर को jboss/bin/native के अंतर्गत तैनात करें।

यह सुनिश्चित करने के लिए कि यह सही फ़ोल्डर में मूल libs की तलाश में है, अपने jboss run.sh संपादित करें।

यह जेबॉस को डिफ़ॉल्ट शुद्ध-जावा वाले लोगों के बजाय देशी एजेपी कनेक्टर ट्रॉड्स का उपयोग करने के लिए मजबूर करेगा।

Answer 7

एजेपी कनेक्टर निष्पादक धागे को लीक करने से संबंधित एक बग है और समाधान Jboss AJP thread pool not released idle threads समझाया गया है। संक्षेप में, डिफ़ॉल्ट रूप से एजेपी थ्रेड-पूल कनेक्शन में कोई टाइमआउट नहीं होता है और एक बार स्थापित होने पर स्थायी रूप से बने रहेंगे। उम्मीद है कि यह मदद करता है,