क्या कोई कारण है कि एसटीए थ्रेड का उपयोग करने के लिए एक प्रबंधित .NET क्लाइंट को सेट करने से मूल COM सर्वर में अपवादों के साथ समस्याएं उत्पन्न हो सकती हैं?

Question

मेरे पास एक मूल (डेल्फी) COM सर्वर है जिसे एसटीए (अपार्टमेंट थ्रेडेड मॉडल) के रूप में विज्ञापित किया जाता है।

इसमें कुछ एल्गोरिदम हैं जो कुछ मामलों में अतिप्रवाह अपवाद फेंकते हैं। इन अपवादों को कोड में संभाला जाता है, और यदि सब कुछ मुख्य थ्रेड पर क्लाइंट से COM सर्वर तक पहुंचता है तो सबकुछ काम करता है।

यदि ग्राहक मूल (डेल्फी) है, तो मैं सर्वर को कई धागे से एक्सेस कर सकता हूं जब तक कि मैं नियम पर चिपक जाता हूं कि थ्रेड पर बनाई गई वस्तु उस सभी थ्रेड से सभी विधि कॉल करती है।

हालांकि यदि क्लाइंट एक प्रबंधित क्लाइंट (Vb.NET और C# परीक्षण किया गया है), यदि मैं क्लाइंट थ्रेड के अपार्टमेंटस्टेट को एमटीए पर सेट करता हूं, तो सब कुछ ठीक काम करता है, लेकिन मुझे एक प्रदर्शन हिट मिलती है।

यह मुझे उम्मीद है, जैसा कि मुझे लगता है कि COM को कुछ जॉगरी पोकर (यानी मार्शलिंग) करना होगा ताकि यह सुनिश्चित किया जा सके कि सभी खुश हैं।

हालांकि अगर मैं अपार्टमेंटस्टेट को एसटीए में बदलता हूं, और इस प्रकार क्लाइंट और सर्वर के बीच सीधा कनेक्शन सुनिश्चित करता है, तो ग्राहक एक गलती त्रुटि के साथ दुर्घटनाग्रस्त हो जाएगा, आमतौर पर CustomMarshallers.dll में System.stackoverflowexception।

यदि मैं इन ओवरफ्लो के कारण संख्याओं को खत्म करता हूं तो मुझे कोई समस्या नहीं है।

मैं अपवादों पर निर्भर नहीं होने के लिए एल्गोरिदम को ट्विक करके इसे प्राप्त कर सकता हूं (शायद उन्हें पहले स्थान पर कैसे लिखा जाना चाहिए), लेकिन मैं क्या हो रहा है इसके पीछे कारणों को समझना चाहता हूं।

Answer 1

इस उत्तर में कुछ अनुमान लगाए गए हैं कि आपने त्रुटि संदेश शब्दकोष उद्धृत नहीं किया है और कोई HRESULT मानों का उल्लेख नहीं किया है।

एक सैद्धांतिक संभावना है कि एसटीए और एमटीए मामलों के बीच विभिन्न उपलब्ध स्टैक स्पेस डेल्फी आवेदन के ढेर के लिए एक अंतर डाल देगा। लेकिन निम्नलिखित संभावना अधिक संभावना है।

StackOverflowException संभवतः डेल्फी पक्ष के कारण होता है (मान लीजिए कि त्रुटि संदेश इसे "अनचाहे" कहता है)। डेल्फी पक्ष पर सभी त्रुटि प्रबंधन तंत्रों के करीब देखो और किसी भी तंत्र के लिए देखें जो विशेष रूप से त्रुटियों पर रिकर्सन का कारण बन सकता है। उदाहरण के लिए, किसी विशेष ईवेंट पर निष्पादित कोड में एक संरक्षित ब्लॉक हो सकता है जहां कैच क्लॉज ऐसा कुछ करता है जो उसी ईवेंट को ट्रिगर करता है।

मुझे लगता है कि यदि आप क्लाइंट कोड से PreserveSigAttribute हटाते हैं तो एसटीए बनाम एमटीए के साथ आप जो अंतर देखते हैं, तो स्टैक ओवरफ़्लो अपवाद को HRESULT में अनुवादित करना बंद कर दिया जाएगा कि आपका ग्राहक संभवतः अभी अनदेखा करता है । (यदि आपने tlbimp.exe का उपयोग किया है, तो यह विशेषता स्पष्ट रूप से निर्दिष्ट हो गई है। इसका मतलब है कि आप वापसी मूल्यों के रूप में COM को अपवादों को संभालना चाहते हैं, न कि अपवाद के रूप में .NET तरीका।)