ज़्यादातर मिडलवेयर एपीआई, SdvResult ऑब्जेक्ट दिखाते हैं. अगर अनुरोध पूरा हो जाता है, तो इस ऑब्जेक्ट में अनुमानित नतीजे वाला ऑब्जेक्ट शामिल होता है. अगर अनुरोध पूरा नहीं होता है, तो इस ऑब्जेक्ट में SdvStatus ऑब्जेक्ट होता है. इससे अनचाहे व्यवहार या गड़बड़ी की स्थिति का पता चलता है. इसकी पहचान अक्सर गड़बड़ी कोड से होती है. जैसे, Internal, Unavailable या DataLoss.
इस पेज पर, इन गड़बड़ी कोड को ठीक करने का तरीका बताया गया है.
रजिस्ट्रेशन और क्रिएशन से जुड़ी समस्याओं को हल करना
रजिस्ट्रेशन और खाता बनाने में समस्याएं आम तौर पर तब आती हैं, जब कोई अमान्य सेवा बनाने या रजिस्टर करने की कोशिश की जाती है.
दूसरी सेवा नहीं बनाई जा सकती
गड़बड़ी:
Internal गड़बड़ी.
वजह:
आपने एक ही सेवा बंडल इंस्टेंस (नाम और इंस्टेंस आईडी) को दो बार रजिस्टर करने की कोशिश की है.
ठीक करें:
एक ही सेवा बंडल इंस्टेंस (नाम और इंस्टेंस आईडी) को दो बार रजिस्टर करने की कोशिश न करें.
डुप्लीकेट सेवा बंडल नहीं मिटाया जा सकता
गड़बड़ी:
Status(-3, EX_ILLEGAL_ARGUMENT)
वजह:
आपने ऐसे डुप्लीकेट सेवा बंडल को मिटाने की कोशिश की है जो मौजूद नहीं है.
ठीक करें:
ऐसे डुप्लीकेट सेवा बंडल को न मिटाएं जो मौजूद नहीं है.
मैसेज भेजने के लिए, पब्लिशर इंस्टेंस को वापस नहीं लाया जा सकता
गड़बड़ी:
take_publisher() को किए गए कॉल से none मिलता है.
वजह:
आपने एक ही सेवा बंडल इंस्टेंस से, एक ही वैरिएंट के लिए take_publisher() को दो बार कॉल किया है.
ठीक करें:
एक ही सेवा बंडल इंस्टेंस से, एक ही वैरिएंट के लिए take_publisher() को दो बार कॉल न करें.
सदस्य, दर्शक, इतिहास या InstantReader नहीं बनाया जा सकता
गड़बड़ी:
Unavailable गड़बड़ी.
वजह:
आपने ऐसे पब्लिशर के लिए Subscriber, Observer, History या InstantReader बनाने की कोशिश की है जो मौजूद नहीं है या जिसका रजिस्ट्रेशन रद्द कर दिया गया है.
ठीक करें:
पुष्टि करें कि पब्लिशर मौजूद है या उसने रजिस्टर किया है. इसके बाद ही, पब्लिशर के लिए Subscriber, Observer, History या InstantReader बनाएं.
RPC क्लाइंट नहीं बनाया जा सकता
गड़बड़ी:
Unavailable गड़बड़ी
वजह:
आपने किसी ऐसे सर्वर यूनिट के नाम के लिए RPC क्लाइंट बनाने की कोशिश की है जो मौजूद नहीं है या रजिस्टर नहीं किया गया है.
ठीक करें:
RPC क्लाइंट बनाने से पहले, पुष्टि करें कि सर्वर मौजूद है और रजिस्टर किया गया है.
कम्यूनिकेशन से जुड़ी समस्याओं को हल करना
किसी सेवा के चालू होने और अन्य सेवाओं से कम्यूनिकेट करने के बाद, कम्यूनिकेशन से जुड़ी गड़बड़ियां हो सकती हैं.
पब्लिशर के तौर पर रजिस्टर किए गए खाते को हटाने से जुड़ी समस्या हल करना
अगर किसी पब्लिशर के पाठक अब भी सक्रिय हैं और वह खुद को डीरजिस्टर कर लेता है, तो गड़बड़ियां हो सकती हैं.
read_next_messages() फ़ंक्शन से, सदस्य के लिए खाली सूचियां दिखती हैं
गड़बड़ी:
read_next_messages() कॉल सफल होता है, लेकिन खाली सूचियां दिखाता है.
वजह:
पब्लिशर को तब डीरजिस्टर किया जाता है, जब उसके पाठक सक्रिय हों.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या स्ट्रीम की उपलब्धता के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध नहीं है, तो पब्लिशर को रजिस्टर नहीं किया जाता है और कोई नया मैसेज नहीं होता है.
Observer के next() फ़ंक्शन में गड़बड़ी हुई
गड़बड़ी:
next() वैल्यू दिखाता है, लेकिन Internal गड़बड़ी हुई है.
वजह:
पब्लिशर को तब डीरजिस्टर किया जाता है, जब उसके पाठक सक्रिय हों.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध नहीं है, तो इसका मतलब है कि पब्लिशर अब मौजूद नहीं है और कोई नया मैसेज नहीं है.
History's read_from_history() फ़ंक्शन, नए मैसेज नहीं दिखाता है
गड़बड़ी:
read_from_history() कोई नया मैसेज नहीं दिखाता है. यह सिर्फ़ पुराने मैसेज दिखाता है.
वजह:
पब्लिशर को तब डीरजिस्टर किया जाता है, जब उसके पाठक सक्रिय हों.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध नहीं है, तो इसका मतलब है कि पब्लिशर अब मौजूद नहीं है और कोई नया मैसेज नहीं है.
InstantReader read_latest_message() में अंदरूनी गड़बड़ी हुई
गड़बड़ी:
read_latest_message() वैल्यू दिखाता है, लेकिन Internal गड़बड़ी हुई है.
वजह:
पब्लिशर को तब डीरजिस्टर किया जाता है, जब उसके पाठक सक्रिय हों.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध नहीं है, तो इसका मतलब है कि पब्लिशर अब मौजूद नहीं है और कोई नया मैसेज नहीं है.
मैसेज की खाली सूची से जुड़ी समस्या हल करना
खाली मैसेज कतार से डेटा पढ़ने की कोशिश करते समय गड़बड़ियां हो सकती हैं.
सदस्यता लेने वाले व्यक्ति के read_next_messages() फ़ंक्शन से कोई सूची नहीं मिलती
गड़बड़ी:
read_next_messages() से खाली सूची मिलती है.
वजह:
पब्लिशर ऐक्टिव है, लेकिन उसने मैसेज नहीं भेजे हैं.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध है, तो इसका मतलब है कि पब्लिशर ऐक्टिव है और कोई नया मैसेज नहीं है.
Observer के next() फ़ंक्शन में गड़बड़ी हुई
गड़बड़ी:
next() वैल्यू दिखाता है, लेकिन Internal गड़बड़ी हुई है.
वजह:
पब्लिशर ऐक्टिव है, लेकिन उसने मैसेज नहीं भेजे हैं.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध है, तो इसका मतलब है कि पब्लिशर ऐक्टिव है और कोई नया मैसेज नहीं है.
History's read_from_history() फ़ंक्शन, नए मैसेज नहीं दिखाता है
गड़बड़ी:
read_from_history() से खाली सूची मिलती है.
वजह:
पब्लिशर ऐक्टिव है, लेकिन उसने मैसेज नहीं भेजे हैं.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध है, तो इसका मतलब है कि पब्लिशर ऐक्टिव है और कोई नया मैसेज नहीं है.
InstantReader read_latest_message() में अंदरूनी गड़बड़ी हुई
गड़बड़ी:
read_latest_message() वैल्यू दिखाता है, लेकिन Internal गड़बड़ी हुई है.
वजह:
पब्लिशर ऐक्टिव है, लेकिन उसने मैसेज नहीं भेजे हैं.
ठीक करें:
सदस्यता लेने वाले व्यक्ति या उपलब्धता स्ट्रीम के इतिहास का इस्तेमाल करें. अगर उपलब्धता स्ट्रीम का आखिरी मैसेज उपलब्ध है, तो इसका मतलब है कि पब्लिशर ऐक्टिव है और कोई नया मैसेज नहीं है.
बफ़र ओवरफ़्लो या डेटा का नुकसान होने की समस्या हल करना
जब पब्लिशर, रीडर की तुलना में ज़्यादा तेज़ी से मैसेज भेजता है, तब गड़बड़ियां हो सकती हैं.
ओवरफ़्लो के बाद, सदस्य के पहली बार पढ़ने पर DataLoss गड़बड़ी दिखती है
गड़बड़ी:
read_next_message() वैल्यू दिखाता है, लेकिन DataLoss गड़बड़ी हुई है.
वजह:
पब्लिशर, मैसेज को इतनी तेज़ी से भेजता है कि कोई व्यक्ति उन्हें पढ़ नहीं पाता.
ठीक करें:
ओवरफ़्लो के बाद, Observer का पहला next() डेटा लॉस की गड़बड़ी दिखाता है
गड़बड़ी:
next() वैल्यू दिखाता है, लेकिन DataLoss गड़बड़ी हुई है.
वजह:
पब्लिशर, मैसेज को इतनी तेज़ी से भेजता है कि कोई व्यक्ति उन्हें पढ़ नहीं पाता.
ठीक करें: गड़बड़ी ठीक करने के ये तरीके अपनाए जा सकते हैं:
पब्लिशर, मैसेज को कम फ़्रीक्वेंसी पर पब्लिश करता है. उदाहरण के लिए, आपके पास सबसे नए मैसेज के टाइमस्टैंप वाला कोई वैरिएबल हो सकता है. अगर मौजूदा समय, पब्लिश करने के सबसे नए समय और डेल्टा से कम है, तो मैसेज पब्लिश नहीं किया जाता. इस तरीके का इस्तेमाल करके, डेल्टा के हिसाब से ज़्यादा से ज़्यादा एक मैसेज पब्लिश किया जाता है.
उपयोगकर्ता, ऑब्ज़र्वर के बजाय
InstantReadऑब्जेक्ट का इस्तेमाल करता है.InstantReadऑब्जेक्ट, ओवरफ़्लो से जुड़ी गड़बड़ियां नहीं दिखाता है. साथ ही, यह हमेशा आखिरी मैसेज दिखाता है. अगर आपको सिर्फ़ आखिरी मैसेज से मतलब है, तो ऑब्ज़र्वर के बजायInstantReadऑब्जेक्ट का इस्तेमाल किया जा सकता है.उपयोगकर्ता सैंपलिंग लागू करता है. अगर आपके समाधान में ऐसा पब्लिशर (P1) है जो ऑब्ज़र्वर (01) के मुकाबले ज़्यादा तेज़ी से मैसेज पब्लिश करता है, तो पब्लिश करने और पढ़ने की स्पीड में अंतर को कम करने के लिए, एक नया पब्लिशर (P2) और ऑब्ज़र्वर (02) बनाया जा सकता है.
उदाहरण के लिए, मान लें कि P1 हर 10 मि॰से॰ में एक मैसेज पब्लिश करता है, लेकिन O1 हर 100 मि॰से॰ में सिर्फ़ एक मैसेज पढ़ सकता है और बाकी नौ मैसेज छोड़ देता है. अंतर को ठीक करने के लिए, ऐसा समाधान बनाएं जिसमें ये चरण शामिल हों:
- P1, O2 को मैसेज पब्लिश करता है.
- O2, एक मैसेज पढ़ता है और नौ मैसेज छोड़ देता है.
- O2, P2 को पढ़े गए मैसेज की सूचना भेजता है.
- P2, पढ़े गए मैसेज की सूचना O1 को भेजता है.
- O1 हर दस सेकंड में एक मैसेज पढ़ता है.
नीचे दिए गए उदाहरण कोड में, सैंपलिंग के इस तरीके को लागू करने का तरीका बताया गया है:
int discarded_message = 10; while (true) { message m = O2.read_message(); if discarded_message == 10 { discarded_message = 0; P2.publish(m); } else { discarded_message ++; } }
इतिहास की जानकारी पूरी नहीं है
गड़बड़ी:
इतिहास की कॉपी से पहले मैसेज मिटा दिया गया है. पढ़े जाने पर, गड़बड़ी की कोई सूचना नहीं मिलती.
वजह:
पब्लिशर, मैसेज को इतनी तेज़ी से भेजता है कि कोई व्यक्ति उन्हें पढ़ नहीं पाता.
ठीक करें:
InstantReader सिर्फ़ आखिरी मैसेज पढ़ता है
गड़बड़ी:
इतिहास की कॉपी से पहले मैसेज मिटा दिया गया है. पढ़े जाने पर, गड़बड़ी की कोई सूचना नहीं मिलती.
वजह:
पब्लिशर, मैसेज को इतनी तेज़ी से भेजता है कि कोई व्यक्ति उन्हें पढ़ नहीं पाता.
ठीक करें:
लागू नहीं
RPC क्लाइंट किसी तरीके को कॉल करता है और वह तरीका उपलब्ध नहीं है
गड़बड़ी:
Unavailable गड़बड़ी की वजह से, तरीके को कॉल नहीं किया जा सका.
वजह:
SDV को सर्वर का नाम नहीं पता होता है और वह Unavailable दिखाता है. यह गड़बड़ी, मिडलवेयर तब दिखाता है, जब सेवा की खोज करने पर मान्य सर्वर का नाम नहीं मिलता.
ठीक करें:
ऐसा सेवा बंडल शुरू करें जो दिए गए इंटरफ़ेस के लिए server तय करता हो. क्लाइंट को इस इंटरफ़ेस का इस्तेमाल करना है.
सर्वर-साइड लागू करने पर SdvStatus गड़बड़ी दिखती है
गड़बड़ी:
सर्वर-साइड लागू करने पर, SdvResult मिलता है. इसमें SdvStatus
गड़बड़ी होती है, जैसे कि SdvStatusCode::NotFound. गड़बड़ी की जानकारी, कॉल करने वाले क्लाइंट को वापस भेज दी जाती है.
वजह:
SDV और क्लाइंट और सर्वर के बीच कम्यूनिकेशन सिस्टम, उम्मीद के मुताबिक काम कर रहा है. हालांकि, क्लाइंट ने ऐसा अनुरोध किया है जिससे सर्वर में गड़बड़ी हुई है.
ठीक करें:
क्लाइंट से मान्य अनुरोध करें या सर्वर को ठीक करें, ताकि उन अनुरोधों का जवाब दिया जा सके.