2016-01-02 7 views
7

अपनी समस्या से एक छोटे संदर्भ देने के लिए ...सही ढंग से साझा करने के लिए कैसे JAX-आरएस 2.0 क्लाइंट

मैं एक जावा EE वेब अनुप्रयोग (एक यूआई/ग्राहक के रूप में) है कि के माध्यम से डेटा/व्यापार तर्क के लिए सेवाओं तक पहुँचता है जेएक्स-आरएस 2.0 क्लाइंट एपीआई (रीस्टेसी कार्यान्वयन) का उपयोग कर एक आरईएसटी इंटरफ़ेस।

वर्तमान में मैं अनुरोध अनुरोधित सीडीआई प्रबंधित बीन का उपयोग करके प्रति अनुरोध एक नया जेएक्सआरएस क्लाइंट इंस्टेंस इंजेक्ट करता हूं, यह सोच रहा है कि क्लाइंट ऐप प्रति अनुरोध एकाधिक बैकएंड संसाधनों को कॉल कर सकता है और मैं पूरे अनुरोध के लिए उसी जेएक्सआरएस क्लाइंट का पुन: उपयोग करता हूं (हालांकि मैंने पढ़ा है कहीं भी यह सही नहीं हो सकता है क्योंकि मैं प्रत्येक आमंत्रण के लिए यूआरआई को संभावित रूप से बदल रहा हूं)

जेएक्सआरएस क्लाइंट के लिए प्रलेखन यह सुझाव देता है कि ग्राहक संभावित रूप से महंगा संचालन है और ऐप को बनाए गए कनेक्शनों की मात्रा को सीमित करना चाहिए। यह खुद को विरोधाभास भी लगता है और एक विशेष वेबटाइटल के सभी अनुरोध समाप्त हो जाने के बाद ग्राहक को बंद होना चाहिए।

क्लाइंट एप्लिकेशन हजारों समृद्ध उपयोगकर्ताओं को संभावित रूप से समर्थन दे सकता है ताकि हजारों 'महंगे ग्राहकों' को बनाना और नष्ट करना सही दृष्टिकोण न लगे, इसलिए मुझे लगता है कि साझा क्लाइंट पूल अधिक उपयुक्त है लेकिन ऐसा प्रतीत नहीं होता है इस बारे में कोई जानकारी कैसे प्राप्त की जानी चाहिए।

सभी उदाहरण अनुरोध के लिए एक नया ग्राहक बनाने के लिए दिखते हैं और ए) इसे बंद करने या बी) इसे बंद नहीं करते हैं, लेकिन वास्तव में यह नहीं बताते कि दूसरे अनुरोध पर क्या होता है।

क्या आप इस बारे में कुछ जवाब देने में मदद कर सकते हैं कि यह कैसे हल किया जाएगा या इस दृष्टिकोण के लिए सबसे अच्छा अभ्यास क्या है इस बारे में जानकारी।

धन्यवाद।

उत्तर

8

एकमात्र "सर्वोत्तम अभ्यास" सलाह है कि मेरे पास seen है या तो खराब प्रदर्शन या जेएक्स-आरएस 2.0 क्लाइंट के साथ खराब मेमोरी उपयोग पैटर्न से बचने के लिए जैक्स-आरएस के जर्सी कार्यान्वयन से संबंधित है और इसलिए यह मान्य नहीं हो सकता है शेष सहज। हालांकि, मुझे संदेह है कि दो कार्यान्वयन इतने समान हैं कि सलाह पोर्टेबल है।

असल में, मेरी समझ पूरी तरह से कॉन्फ़िगर क्लाइंट मामलों की एक छोटी संख्या बनाने के लिए

  • उपयोग ClientBuilder है - आप विभिन्न स्थितियों में अलग अलग कॉन्फ़िगरेशन (उदा क्रमबद्धता/Deserialisation प्रदाता) के साथ अलग-अलग ग्राहकों पड़ सकता है। इस प्रकार की चीज शायद एप्लिकेशन प्रारंभिकरण, या इसी प्रकार की 'दुर्लभ' घटनाओं के आसपास होनी चाहिए।
  • समान कॉन्फ़िगरेशन आवश्यकताओं वाले वर्गों के बीच प्रत्येक पूर्ण-कॉन्फ़िगर किए गए क्लाइंट इंस्टेंस को साझा करें। आप अपने DI ढांचे को बता सकते हैं, उदाहरण के लिए, उन क्लाइंट उदाहरणों में से प्रत्येक को @Singleton के रूप में गुंजाइश करने के लिए।
  • अंतर्निहित कॉन्फ़िगरेशन को संशोधित करने वाले क्लाइंट इंस्टेंस पर किसी भी विधि को कॉल करने से बचें। उदाहरण register(Class<T> componentClass) जैसी चीजें हैं - javax.ws.rs.core.Configurable इंटरफ़ेस पर बहुत कुछ भी।
  • एक साझा क्लाइंट का उपयोग कर प्रत्येक इंस्टेंस ऑब्जेक्ट (और चाहिए?) अपने स्वयं के, निजी और गैर-साझा, वेबटेक्शंस बना सकता है। प्रभावी रूप से, यह वेब लक्ष्य है जो @RequestScoped होना चाहिए और ग्राहक नहीं।
  • हालांकि, क्लाइंट के साथ, वेबटाइटल का उपयोग करने वाले किसी भी चीज़ को javax.ws.rs.core.Configurable इंटरफ़ेस विधियों के माध्यम से किसी भी डीलिंग करने से बचना चाहिए।

इसके बाद यह काफी सादा नौकायन है।

संबंधित मुद्दे