當工作線程繼續時，主線程能否在RESTful webservice中結束？

我有一個Java REST風格的web服務，每隔10秒會被另一個進程調用。如果條件正確，Web服務需要執行一個潛在的廣泛的ETL過程（比如說10-20秒）。但是，我們希望立即返回調用應用程序，指出已將有效內容成功傳遞到Web服務。當工作線程繼續時，主線程能否在RESTful webservice中結束？

要求摘要：

驗證認證和輸入參數。
如果驗證失敗，則返回XML中的錯誤。
啓動執行ETL過程的線程。過程只會在某些條件下進行。
返回指示已發送的有效負載和已通過輸入驗證的XML。

我已經編寫這一點，它似乎正常運行。但這看起來不正確。我創建的線程可能比主Web服務線程運行時間更長。

任何人都想指點我一個更好的方式來做到這一點？

來源

2011-10-28 BigRedBettaFish

這是正確的做法。解決方案有什麼「看起來不正確」？

我唯一的建議是，你不應該只是發射線程無所畏懼。你應該有某種共享的ExecutorService來管理這些ETL進程線程。這將使您瞭解已啓動並仍在運行的內容以及限制/控制後臺進程數量（並可能處理任何流氓執行）的能力。

您也可能想要爲啓動的進程生成某種「jobId」並將其返回給調用者。那麼你可以添加一個呼叫到你的API，客戶可以使用它來檢查工作狀態。

來源

2011-10-28 14:31:03 jtahlborn

謝謝你的想法。我已經在一個單例中實現了一個ExecutorService。我還在我的線程類中使用Callable <>接口，以便我可以跟蹤線程的結果並稍後介紹一些代碼來檢查失控線程。 – BigRedBettaFish

......然而，我們要返回到調用應用程序馬上指示載荷已成功傳遞到Web服務...

這聽起來像你想返回成功/失敗消息後直接驗證，然後再次如果包含成功請求的響應。

雖然沒有技術上的原因這是行不通的，在典型的RESTful Web服務的交流有一對一的HTTP調用請求的比例，此架構將被潛在返回兩個響應的一個請求打破。這可能會混淆不是你或你公司的客戶。

我可能會建議實施可以異步與在第一服務請求返回的車票查詢額外的回調服務。當您等待返回交易結果時，這具有不會阻止服務1的額外好處。

只要您的負載很低，爲事務啓動另一個線程就沒問題。如果太高您的要求將開始超時，當你不能啓動任何更多的線程

來源

2011-10-28 14:34:33 jpredham

正如你能打出提交任務，執行任務的責任的替代品。您的提交部分已經停止 - 您的Web服務接收到請求並進行驗證，但不會立即產生線程來執行它，您可以將其保存到外部存儲中。

然後在cron上運行一個簡單的計劃任務（Quartz），以接收新任務並執行它們。

這種方法的優點是更強的解耦和更多的系統靈活性（Web服務正在關閉不會影響任務執行，反之亦然）。控制檯是系統中更多移動部件（組件）。

在任何情況下，您當前的設置工作，你在正確的軌道上。

來源

2011-10-28 14:37:37 Perception

當工作線程繼續時，主線程能否在RESTful webservice中結束？

回答

相關問題