मेरे पास एक प्रक्रिया है जहां मुझे फ़ाइल को Sftp सर्वर पर असीमित रूप से अपलोड करने की आवश्यकता है। इसलिए गेटवे में Async के बारे में और अधिक खोज करने के बाद मैंने पाया कि मुझे त्रुटि चैनल को @MessagingGateway पैरामीटर में परिभाषित करने की आवश्यकता है, फिर त्रुटि चैनल के लिए प्रचारित अपवाद को संभालने के लिए हैंडलर लेकिन मुझे लगा कि इस तरह से संभालना मेरे लिए जटिल है, जैसा कि मेरे पास होगा Pojo फ़ील्ड को अपडेट करने और फ़ाइल अपलोड, सफलता या विफलता के आधार पर DB में बने रहने के लिए।

इसलिए मैंने @Async के साथ एनोटेट की गई एक कस्टम विधि के बारे में सोचा और गेटवे विधि को कॉल किया। कोशिश ब्लॉक के साथ गेटवे विधि को भी घेरें और डाउनस्ट्रीम में होने वाले किसी भी अपवाद को पकड़ें

कोड नमूना:

 @Async
void upload(Resource file, FileStatus fileStatus){
    try{
        uploadGateway.upload(file,fileStatus.getFilePath(),fileStatus.getFileName());
    }catch(RuntimeException e){
        fileStatus.setUploadStatus("Failed");
        //save into db
    }
}

त्रुटि चैनल के बिना गेटवे अपलोड करें ताकि त्रुटि कॉलर को वापस भेजी जा सके

 @MessagingGateway
 public interface UploadGateway {


@Gateway(requestChannel = "input.channel")
void upload(@Payload Resource file, @Header("path") String path, @Header("name") String fileName);
}

हैंडलर:

 @Bean
public IntegrationFlow uploadDocument() {
    return IntegrationFlows.from("input.channel")
            .log(LoggingHandler.Level.WARN)
            .handle(Sftp.outboundAdapter(sftpSessionFactory(), FileExistsMode.FAIL)
                    .autoCreateDirectory(true)
                    .remoteDirectoryExpression("headers['path']")
                    .fileNameExpression("headers['name']"))
            .get();
}

प्रश्न: यदि मैं इस तरह से त्रुटि को संभाल रहा हूँ तो परिणाम क्या होंगे? क्या डाउनस्ट्रीम फ्लो में हुई किसी त्रुटि को संभालने का यह सही तरीका है?

1
abdur rehman 4 फरवरी 2021, 15:56

1 उत्तर

सबसे बढ़िया उत्तर

चूंकि @MessagingGateway मैसेजिंग में RPC की तरह है, इसलिए इसके मेथड कॉल पर अपवाद को पकड़ना पूरी तरह से ठीक है। चूंकि आप अपने प्रवाह को पूरी तरह से सिंक करते हैं, यह सामान्य जावा अपवाद उप-प्रणाली की तरह काम करता है।

errorChannel के साथ एसिंक त्रुटि प्रबंधन के बारे में आपकी चिंता वास्तव में समझ में आती है क्योंकि यह मानक जावा एसिंक विधि प्रबंधन और इसकी त्रुटियों के प्रसंस्करण के साथ जटिलता में समान है।

दूसरी ओर errorChannel के माध्यम से डाउनस्ट्रीम त्रुटियों को संभालने के लिए वास्तव में सराहना की जाती है यदि यह किसी अन्य प्रवाह में कुछ जटिल तर्क होने जा रहा है। साथ ही आप कुछ मुआवजा संदेश वापस करने जा रहे हैं।

हालांकि दिन के अंत में चुनाव आपका है: त्रुटियों को स्वयं संभालने में कोई कमी नहीं है।

देखें त्रुटि प्रबंधन अधिक भोजन पर विचार करने के लिए अध्याय।

1
Artem Bilan 4 फरवरी 2021, 18:35
क्या होगा यदि मेरा प्रवाह या हैंडलर भी एसिंक्रोनस है और कॉलर के थ्रेड पर निष्पादित नहीं होता है तो क्या यह अभी भी काम करेगा? या क्या मुझे त्रुटि चैनल तंत्र को पेश करना होगा?
 – 
abdur rehman
4 फरवरी 2021, 21:49
नहीं, तुम नहीं। जब हम गेटवे से कोई संदेश भेजते हैं, तो हम errorChannel हेडर जोड़ते हैं। आम तौर पर TaskExecutor ढांचे में एक ErrorHandlingTaskExecutor में लपेटा जाता है जो जानता है कि उस शीर्षलेख के साथ क्या करना है। भले ही यह एक एसिंक डाउनस्ट्रीम है, फिर भी यह गेटवे में सिंक है: यह TemporaryReplyChannel में एक उत्तर की प्रतीक्षा करता है, जो errorChannel हेडर के माध्यम से इसमें रखे गए अपवाद को फिर से फेंक सकता है।
 – 
Artem Bilan
4 फरवरी 2021, 21:53