我檢查了一些 Java RMI 示例。但是它們都沒有演示如何從潛在的服務器故障或 RemoteException 中恢復，這可能是我們定義的遠程介面拋出的。我也找不到任何相關資訊。
例如，
public static void main(String[] args)
{
try
{
Server server = new Server();
Hello stub = (Hello) UnicastRemoteObject.exportObject(server, 0);
Naming.rebind("rmi://localhost/Hello", stub);
System.out.println("Server is up.");
}
catch (RemoteException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
catch (MalformedURLException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
例外被捕獲后，服務器就退出了。當拋出此類例外時，服務器是否會死機？我們能否從此類故障中恢復，例如重新啟動服務器？但是怎么做？
謝謝，
- - - - - -更新 - - - - -
澄清一下，最初，我認為遠程介面中指定的 RemoteException 可能會在這里捕獲。但是經過一些實驗，我發現它們實際上會出現在客戶端，應該由客戶端處理。
uj5u.com熱心網友回復：
您的 RMI 服務器僅在初始化/啟動時拋出該UnicastRemoteObject.exportObject例外Naming.rebind。很可能這里的任何錯誤都不能簡單地通過運行一個回圈來再次執行相同的操作來恢復。還有一些其他問題需要調查。
如果您的服務器通過exportObject/rebind您會看到“服務器已啟動”訊息，則執行將通過 catch 塊并main(String[] args)正常結束。甚至執行緒處理[main]也可能到此結束。
但是，JVM 行程不會退出，因為有非守護執行緒正在運行。服務器中的任何例外都不會傳遞回catch(RemoteException e)main 中顯示的塊，因為main()已經結束。
在實時系統中，我觀察到開發人員用來解決 RMI 服務器問題的幾種措施：
- 服務器啟動腳本使用有限回圈在死機時重試啟動（如果它在很長一段時間后死機而不是立即失敗，這會更有效）
- 定期往返 rmi 客戶端到服務器呼叫，通過簡單的操作來證明 RMI 服務器的健康狀況
- 運行多個 rmi 服務器實體，并在不同時間故意關閉重啟周期，以確保 100% 運行
- rmi 服務器上的行程監視器 => 觸發警報以進行手動干預
最重要的是，您需要有效的日志記錄，這樣您就可以診斷出它后來死亡的原因。
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/517463.html
標籤：爪哇例外rmi
上一篇：在PySpark中通過例外