2008-11-11 6 views
7

में सर्वर टाइमआउट की गहन हैंडलिंग मेरे पास एक फ्लेक्स क्लाइंट है जो BlazeDS चलाने वाले टॉमकैट सर्वर पर सेवा कॉल करता है। मैं इस माहौल में सर्वर सत्र टाइमआउट को गहन रूप से संभालना चाहता हूं।BlazeDS

मेरे पास सेवा पर सुरक्षा बाधाएं हैं, इसलिए क्लाइंट गंतव्य के आधार पर चैनलसेट प्रारंभ करके और उस चैनलसेट का उपयोग करके लॉग इन करके रिमोट ऑब्जेक्ट के विरुद्ध प्रमाणित करता है।

उपयोगकर्ता प्रमाणीकृत होने के बाद, यदि उन्हें कॉफी (लंबी) कप मिलती है, तो उनका सत्र अनिवार्य रूप से समाप्त हो जाएगा।

मैं क्लाइंट को टाइमआउट का पता लगाने के लिए चाहूंगा, और उपयुक्त सूचना संदेशों के साथ उपयोगकर्ता को लॉगिन पृष्ठ पर वापस कर दूंगा।

लेकिन मुझे क्लाइंट से इस टाइमआउट का पता लगाने का सबसे अच्छा तरीका खोजने में कठिनाई हो रही है। क्या यह संभव है, या जब सर्वर टाइमआउट होता है तो सर्वर को एक त्रुटि फेंकनी चाहिए?

धन्यवाद!

उत्तर

0

दस्तावेज़ों को देखें और देखें कि कनेक्शन डिस्कनेक्ट होने पर कोई ईवेंट निकाल दिया गया है या नहीं। मैं कल्पना करता हूं कि वहां है। यदि नहीं, तो अपने कनेक्शन के चारों ओर प्रयास करें/पकड़ें और किसी भी कनेक्शन से जुड़े मुद्दों को पकड़ें। यदि आप करते हैं, तो अपने ऐप को रीडायरेक्ट करें और उपयोगकर्ता को सूचित करें। आपको कनेक्शन समस्याओं के लिए सही त्रुटि कोड फेंकने के लिए शायद इसके साथ खेलने की आवश्यकता होगी लेकिन यह डिबगिंग में काफी आसान होना चाहिए।

0

मुझे एक परियोजना पर इस मुद्दे का सामना करना पड़ा, विशेष रूप से क्योंकि ब्लज़ेड्स के पास वास्तविक एप्लिकेशन (क्लीयरट्रस्ट के माध्यम से आर्किटेक्चर पर सिंगल-साइन का उपयोग करके) का एक अलग सत्र टाइमआउट था। ध्यान दें, यह एक जेबॉस पर्यावरण में था। मैं गलती हैंडलरों में 2 विशिष्ट गलतियों को ढूंढकर एक साधारण सरल दृष्टिकोण ले रहा था (एक सामान्य गलती हैंडलर के साथ एक बेस क्लास था): डुप्लिकेट सत्र और डिलीवरीइन डबेट। जब भी BlazeDS ने उसी JBoss सत्र आईडी के लिए एक नया सत्र बनाने का प्रयास किया तो मैंने डुप्लिकेट सत्र को देखा। डिलिवरीइन डबेट कभी-कभी दिखाने के लिए प्रवृत्त होता है, लेकिन मुझे यकीन नहीं है कि क्यों। जब मैंने उन गलती कोड को देखा, तो मैंने ऐप को रीफ्रेश करने के लिए आवश्यक कार्रवाई की (आपकी ज़रूरतों के आधार पर, आप लॉगिन पेज पर रीडायरेक्ट कर सकते हैं या कुछ और)। जाहिर है, पर्यावरण के आधार पर, आपको एक अलग गलती कोड सुनना पड़ सकता है, और यह दृष्टिकोण अलग-अलग वातावरण/कॉन्फ़िगर/आदि के अनुसार हर स्थिति में काम नहीं कर सकता है।

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

+0

आप BlazeDS का किस संस्करण का उपयोग कर रहे हैं? – Rydell

+0

हम 3.2.0.3978 – pinkeerach

1

हमने क्लाइंट कैप्चरिंग कीस्ट्रोक और माउस ईवेंट के लिए एक कस्टम घटक लिखा और फिर क्लाइंट पर टाइमआउट प्रबंधित करें।

+0

का उपयोग कर रहे हैं क्लाइंट पक्ष पर टाइमआउट का पता लगाने का कोई तरीका नहीं है, इसलिए यह आदर्श समाधान है। यदि आप क्लाइंट पर टाइमआउट को थोड़ा कम करने के लिए सेट करते हैं तो सर्वर यह वास्तव में अच्छी तरह से काम करता है। –

+1

'आईडीईई' घटना आपके लिए बाहर के बॉक्स को हल करेगी: http://bit.ly/cQljgq –

0

मुझे अपनी परियोजनाओं में से एक में इस समस्या का सामना करना पड़ा। जब मैंने रिमोट ऑब्जेक्ट या एचटीटीपीएस सेवा के माध्यम से क्लाइंट तक सर्वर तक पहुंचना है, तो यह हर बार होता है, यह पहले उपयोगकर्ता के प्रमाणीकरण की जांच करता है, अगर यह पहले से ही टाइम-आउट है, तो यह कुछ वापस कर देगा और यदि यह ठीक है तो यह इसकी प्रक्रिया जारी रखेगा। क्लाइंट साइड के प्रतिक्रिया हैंडलर परिणाम ईवेंट में, ग्राहक जांच करता है कि प्रतिक्रिया टाइमआउट के लिए है और यदि ऐसा है, तो यह पृष्ठ को फिर से लॉगिन करने के लिए आगे बढ़ेगा। जहां तक ​​मुझे पता है कि उपयोगकर्ता का सत्र समय समाप्त होने पर सर्वर क्लाइंट को कोई त्रुटि नहीं देगा। आपको बस सर्वर पर अगली पहुंच पर सत्र का समय-समय पता चल जाएगा।

0

सर्वर-पक्ष पर FlexSessionListener इंटरफ़ेस को कार्यान्वित करें। यह वास्तव में किए जाने से पहले फ्लेक्स सत्र निर्माण/विनाश को संभालने का एक तरीका प्रदान करता है।

सत्र पर डिस्ट्रायर्ड हैंडलर, सर्वर से सर्वर से संदेश भेजने के लिए एक संदेश निर्माता का उपयोग करें ताकि उसे पता चल सके कि सत्र समय-समय पर है।

+0

समस्या यह है कि फ्लेक्स सत्र और फ्लेक्स क्लाइंट सार वर्ग केवल सत्र/ग्राहक घटनाएं बनाते हैं। कोड को देखते हुए, नष्ट श्रोताओं का सेट एक ही स्थिर तरीके से संग्रहीत नहीं होता है, इसलिए कक्षाओं को ओवरराइड करने से यह करने का एक आसान तरीका नहीं मिलेगा। मुझे लगता है कि उन्होंने ब्लूज़डीएस एपीआई के अंतिम उपयोगकर्ताओं को सर्वर तरीके से ऐसा करने का एक आसान तरीका दिया – Alex

1

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

1

यह BlazeDS के लिए विशिष्ट नहीं है, लेकिन फ्लेक्स 4.5 (संभवतः पहले) के रूप में वहाँ टाइमआउट त्रुटियों के लिए गलती घटना पर एक विशिष्ट गलती कोड है:

तुम्हारी गलती हैंडलर में:

if(faultEvent.fault.faultCode == "Client.Error.RequestTimeout"){ 
    trace("TIMEOUT ERROR"); 
} 
0

बढ़ाएँ CallResponder, और गलती विधि को ओवरराइड करें।

ज्ञात त्रुटि कोड, जैसे ErrorMessage.MESSAGE_DELIVERY_IN_DOUBT के लिए data.fault.faultCode जांचें।

यदि आपको हिट मिलती है, तो रीडायरेक्ट करने के लिए मूल फ़ंक्शन नेविगेट ToURL का उपयोग करें।

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