असल में मैं कहूंगा कि जेएमएस के लिए सुनना शायद एक सर्वर सर्वर के लिए सबसे अच्छा कारण है। एक स्टैंड अकेले संदेश दलाल समस्या को ठीक नहीं करता है क्योंकि आपको अभी भी ऐसे घटक की आवश्यकता है जो संदेशों को सुन रहा हो। ऐसा करने का सबसे अच्छा तरीका एमडीबी का उपयोग करना है। सिद्धांत रूप में आप स्प्रिंग्स MessageListenerContainer का उपयोग कर सकते हैं। हालांकि इस तरह के कई नुकसान हैं जैसे कि जेएमएस केवल पढ़ने को अवरुद्ध करने का समर्थन करता है और इसलिए वसंत को अपने स्वयं के धागे को स्पिन करने की आवश्यकता होती है जो पूरी तरह से असमर्थित (यहां तक कि टॉमकैट में) है और लेनदेन, सुरक्षा, नामकरण (जेएनडीआई) और कक्षा लोडिंग को तोड़ सकता है (जो बदले में टूट सकता है दूरस्थ)। एक जेसीए संसाधन एडाप्टर जो कुछ भी चाहता है वह करने के लिए स्वतंत्र है वर्कमैनेजर के माध्यम से थ्रेड कताई सहित। संभावना है कि जेएमएस (या अन्य गंतव्य) के अलावा एक डेटाबेस का उपयोग किया जाता है, जिस बिंदु पर आपको एक्सए-लेनदेन और जेटीए की आवश्यकता होती है, दूसरे शब्दों में एक एप्लीकेशन सर्वर। हां आप इसे सर्वलेट कंटेनर में पैच कर सकते हैं लेकिन यह बिंदु यह एप्लिकेशन सर्वर से अलग नहीं हो सकता है।
आईएमएचओ अनुप्रयोग सर्वर के खिलाफ सबसे बड़ा कारण यह है कि एक spec प्रकाशित होने के कई सालों बाद (जो बदले में भी वर्षों लेता है) जब तक कि सेवर्स ने spec को लागू नहीं किया है और सबसे खराब बग को बाहर निकाला है। केवल अब, ईई 7 प्रकाशित होने से ठीक पहले क्या हमारे पास ईई 6 सर्वर दिखने लगे हैं जो पूरी तरह से बग के साथ नहीं हैं। यह उस बिंदु पर हास्यपूर्ण हो जाता है जहां कुछ विक्रेता अब अपनी ईई 6 लाइन में बग ठीक नहीं करते हैं क्योंकि वे आगामी ईई 7 लाइन के साथ पहले ही व्यस्त हैं।
संपादित अंतिम अनुच्छेद की
लांग स्पष्टीकरण: स्थानों का एक बहुत में
जावा ईई क्या प्रासंगिक जानकारी कहा जाता है पर निर्भर करता है। सूचना जो सर्वर/कंटेनर से आवेदन के लिए स्पष्ट रूप से एक तर्क के रूप में पारित नहीं है लेकिन स्पष्ट रूप से "वहां" है। उदाहरण के लिए सुरक्षा जांच के लिए वर्तमान उपयोगकर्ता। वर्तमान लेनदेन या कनेक्शन। कक्षाओं को आलसी लोड कोड या वस्तुओं को deserialize करने के लिए कक्षाओं को देखने के लिए वर्तमान आवेदन। या जेएनडीआई लुकअप करने के लिए वर्तमान घटक (सर्वलेट, ईजेबी, ...)। यह सारी जानकारी थ्रेड लोकल में है कि सर्वर/कंटेनर एक घटक (सर्वलेट, ईजेबी, ...) को कॉल करने से पहले सेट करता है। यदि आप अपना खुद का धागे बनाते हैं तो सर्वर/कंटेनर उनके बारे में नहीं जानता है और इस जानकारी पर निर्भर सभी सुविधाएं अब काम नहीं करती हैं। आप अपने द्वारा उत्पन्न धागे में उन सुविधाओं में से किसी एक का उपयोग न करके इस से दूर हो सकते हैं।
कुछ लिंक
http://www.oracle.com/technetwork/java/restrictions-142267.html#threads http://www.ibm.com/developerworks/websphere/techjournal/0609_alcott/0609_alcott.html#spring-4
हम सर्वलेट 3.0 विनिर्देश जाँच अगर हमें पता चलता:
2.3.3.3 अतुल्यकालिक प्रसंस्करण
जावा एंटरप्राइज़ संस्करण धारा 15.2 के रूप में ऐसी सुविधाओं पृष्ठ 2-174 और धारा 15.3.1 पर "वेब अनुप्रयोग पर्यावरण", "सेकू का प्रचार ईजेबीटीएम कॉल में rity पहचान "पृष्ठ 15-176 पर केवल प्रारंभिक अनुरोध को निष्पादित करने वाले थ्रेड के लिए उपलब्ध है या जब AsyncContext.dispatch विधि के माध्यम से कंटेनर को अनुरोध भेजा जाता है। जावा एंटरप्राइज़ संस्करण सुविधाएं AsyncContext.start (Runnable) विधि के माध्यम से प्रतिक्रिया ऑब्जेक्ट पर सीधे चल रहे अन्य थ्रेडों के लिए उपलब्ध हो सकती हैं।
यह असीमित प्रक्रिया के बारे में है लेकिन कस्टम थ्रेड के लिए एक ही प्रतिबंध लागू होते हैं।
सार्वजनिक शून्य प्रारंभ (रननेबल आर) - यह विधि निर्दिष्ट रननेबल चलाने के लिए कंटेनर को संभवतः एक प्रबंधित थ्रेड पूल से थ्रेड भेजने का कारण बनती है। कंटेनर रननेबल को उपयुक्त प्रासंगिक जानकारी प्रसारित कर सकता है।
फिर, एसिंक्रोनस प्रोसेसिंग लेकिन कस्टम थ्रेड के लिए एक ही प्रतिबंध लागू होते हैं।
15.2.2 वेब अनुप्रयोग पर्यावरण
सर्वलेट कंटेनर के इस प्रकार जब डेवलपर द्वारा बनाया धागे पर प्रदर्शन किया, लेकिन वर्तमान में तो करने के लिए आवश्यक नहीं कर रहे हैं इस व्यवहार का समर्थन करना चाहिए। इस तरह के एक आवश्यकता को इस विनिर्देश के अगले संस्करण में जोड़ा जाएगा। डेवलपर्स को चेतावनी दी जाती है कि आवेदन-निर्मित धागे के लिए इस क्षमता के आधार पर अनुशंसित नहीं है, क्योंकि यह गैर-पोर्टेबल है।
गैर पोर्टेबल का मतलब है कि यह एक सर्वर में हो सकता है लेकिन दूसरे में नहीं।
आप JMS साथ संदेश प्राप्त करते हैं बाहर एक एमडीबी के आप चार विधियों javax.jms.MessageConsumer पर उपयोग कर सकते हैं चाहते हैं: यह करने के लिए एक कंटेनर सूत्र में
#receiveNoWait() आप कर सकते हैं, यह ब्लॉक नहीं करता है, लेकिन यह देखना पसंद है । अगर कोई संदेश मौजूद नहीं है तो यह null लौटाता है। यह संदेशों को सुनने के लिए बहुत उपयुक्त नहीं है।#receive(long) आप इसे कंटेनर थ्रेड में कर सकते हैं, यह ब्लॉक करता है। आप आम तौर पर एक कंटेनर थ्रेड में अवरुद्ध करने की प्रतीक्षा नहीं करते हैं। संदेशों को सुनने के लिए फिर से बहुत उपयुक्त नहीं है।#receive(), यह ब्लॉक संभवतः अनिश्चित काल तक। संदेशों को सुनने के लिए फिर से बहुत उपयुक्त नहीं है।#setMessageListener() यह वही है जो आप चाहते हैं, जब कोई संदेश आता है तो आपको कॉलबैक मिल जाता है। हालांकि जब तक कि लाइब्रेरी एप्लिकेशन सर्वर में हुक नहीं कर लेती है, यह एक कंटेनर थ्रेड नहीं होगा। एप्लिकेशन सर्वर में हुक केवल संसाधन अनुकूलक के लिए जेसीए के माध्यम से उपलब्ध हैं।
तो हाँ, यह काम कर सकता है, लेकिन इसकी गारंटी नहीं है और ऐसी कई चीजें हैं जो टूट सकती हैं।
'हालांकि यह कई नुकसान JMS केवल अवरुद्ध पढ़ता है और वसंत इसलिए यह की अपनी धागे ऊपर स्पिन जो पूरी तरह असमर्थित (बिलाव में भी) है और लेन-देन, सुरक्षा तोड़ सकते हैं की जरूरत है का समर्थन करता है की तरह है, नामकरण (जेएनडीआई) और कक्षा लोडिंग (जो बदले में रिमोटिंग तोड़ सकती है)। क्या आप मुझे दिखा सकते हैं कि आपको यह कहां मिला? मुझे यकीन है कि कुछ लोग ऐप सर्वर के बिना स्वतंत्र संदेश दलाल के साथ वसंत का उपयोग करते हैं। यह पता लगाने की कोशिश कर रहा है कि कोई भी इस समस्या को कहीं भी लाया है या नहीं। यह नहीं कह रहा कि आप गलत हैं! :-) अधिक अंतर्दृष्टि प्राप्त करने की कोशिश कर रहा है। –