मुझे इस समस्या का सामना कुछ बार हुआ है, और मैं किसी भी समाधान को समझने में सक्षम नहीं हूं लेकिन मामूली एक (नीचे देखें)।आर पैकेज को अद्यतन करने के लिए सुरक्षित तरीका - "हॉट-स्वैपिंग" संभव है?
मान लीजिए कि कोई कंप्यूटर 2+ उपयोगकर्ता या 1 उपयोगकर्ता एकाधिक प्रक्रियाओं को चलाने के कारण आर के 2+ उदाहरण चला रहा है, और एक उदाहरण update.packages() निष्पादित करता है। मेरे पास कई बार है जहां दूसरा उदाहरण बड़ा समय निकाल सकता है। अद्यतन किए जा रहे संकुल कार्यक्षमता को किसी भी तरह से परिवर्तित नहीं करते हैं जो गणना को प्रभावित करता है, लेकिन किसी भी तरह से एक बड़ी समस्या उत्पन्न होती है।
मामूली समाधान (समाधान 0) आर के सभी उदाहरणों को समाप्त करना है जबकि update.packages() निष्पादित करता है। इसमें 2+ समस्याएं हैं। सबसे पहले, किसी को आर उदाहरणों को समाप्त करना होगा। दूसरा, कोई भी यह पहचानने में सक्षम नहीं हो सकता है कि वे उदाहरण कहां चल रहे हैं (अपडेट 1 देखें)।
मानते हैं कि निष्पादित किए जा रहे कोड का व्यवहार नहीं बदलेगा (उदाहरण के लिए पैकेज अपडेट सभी फायदेमंद हैं - वे केवल बग ठीक करते हैं, गति में सुधार करते हैं, रैम को कम करते हैं, और यूनिकॉर्न देते हैं), क्या हॉट-स्वैप करने का कोई तरीका है पैकेज की नई संस्करण अन्य प्रक्रियाओं पर कम प्रभाव के साथ?
मैं आर के बाहर दो और उम्मीदवार समाधान है,:
समाधान 1 एक अस्थायी पुस्तकालय पथ का उपयोग और उसके बाद वर्ष पुराने पुस्तकालय हटा सकते हैं और अपनी जगह में नया ले जाने के लिए है। इसका दोष यह है कि हटाए गए + कदम कुछ समय लग सकते हैं जिसके दौरान कुछ भी उपलब्ध नहीं है।
समाधान 2 लाइब्रेरी (या लाइब्रेरी पदानुक्रम) को इंगित करने के लिए सिम्लिंक का उपयोग करना है और एक नई लाइब्रेरी में एक पॉइंटर के साथ सिमलिंक को ओवरराइट करना है जहां अद्यतन पैकेज रहता है। ऐसा लगता है कि ओएस के लिए सिमलिंक को ओवरराइट करने में लगने वाला समय भी कम पैकेज डाउनटाइम होता है। इसका नकारात्मक पक्ष यह है कि इसे सिम्लिंक के प्रबंधन में बहुत अधिक देखभाल की आवश्यकता होती है, और यह प्लेटफार्म-विशिष्ट है।
मुझे लगता है कि समाधान # 1, # 2 की तरह बनना .libPaths() के चतुर उपयोग द्वारा संशोधित किया जा सकता है, लेकिन यह लगता है एक के लिए नहीं कॉल update.packages() की जरूरत है और इसके बजाय कि पुरानी पड़ चुकी संकुल पाता है एक नया अपडेटर लिखने की तरह, यदि इंस्टॉल उन्हें एक अस्थायी पुस्तकालय में, और फिर लाइब्रेरी पथ अद्यतन करता है। इसका उछाल यह है कि कोई भी .libPaths() पर मौजूदा प्रक्रिया को बाधित कर सकता था जब यह शुरू हुआ था (यानी लाइब्रेरी पथ आर को बदलना, उन उदाहरणों के लिए प्रचारित नहीं किया जा सकता है जो पहले से चल रहे हैं, उस उदाहरण के भीतर कुछ स्पष्ट हस्तक्षेप किए बिना)।
अद्यतन 1. उदाहरण परिदृश्य में, दो प्रतिस्पर्धी आर उदाहरण एक ही मशीन पर हैं। यह एक आवश्यकता नहीं है: जहां तक मैं अद्यतनों को समझता हूं, यदि दोनों एक ही पुस्तकालयों को साझा करते हैं, यानी साझा ड्राइव पर एक ही निर्देशिका, तो अद्यतन अभी भी समस्याएं पैदा कर सकता है, भले ही आर का अन्य उदाहरण किसी अन्य मशीन पर हो । तो, कोई गलती से आर प्रक्रिया को मार सकता है और इसे भी नहीं देख सकता है।
यह एक है महत्वपूर्ण बिंदु। मुझे संदेह है कि साझा लाइब्रेरी का मुद्दा ऑपरेटिंग सिस्टम में एक समस्या है। अधिकांश उपयोग के लिए, मुझे विश्वास है कि यह हॉटस्पैपिंग के विचार को मारता है। सबसे संगत केस उन पैकेजों के लिए होगा जो बाह्य साझा पुस्तकालयों का उपयोग नहीं करते हैं, लेकिन मुझे यकीन नहीं है कि यह उन पैकेजों के लिए कैसे काम करता है जो पूरी तरह से आर – Iterator
में हैं, मुझे लगता है कि आपका उत्तर सामान्य रूप से हॉटस्पैपिंग के सपने को बहुत अधिक क्रश करता है। यहां तक कि अगर मेरे पास एक शुद्ध आर पैकेज है जो मैं हॉटस्पेप करना चाहता हूं, तो यह मानने के लिए यह एक अच्छा अभ्यास नहीं है कि मैं यह कर सकता हूं। विन्सेंट को एक उचित जवाब मिला कि स्वैपिंग के बजाए कोई संस्करण कैसे कर सकता है, जिसे मुझे थोड़ा सा अनुकूलित करना होगा, लेकिन यह स्पष्ट है कि आपके द्वारा बताए गए संघर्षों के आसपास यही एकमात्र तरीका है। – Iterator