[v18]「このプロセスの接続は中断されたか、実行できませんでした」
2 posters
Re: [v18]「このプロセスの接続は中断されたか、実行できませんでした」
このダイアログは,アプリケーションサーバー(いわゆる19813通信)が失敗したタイミングで表示されものであり,ネットワーク障害(まれ)またはサーバー終了(ほとんどのケース)が示唆されています。
後者の場合,再起動しても接続する相手がいないという問題が残りますが,サーバー自体も自動的に復旧するのであれば,やってみる価値はあるかもしれません。前者の場合,ルーターやタイムアウトの設定(データベースパラメーター#54),ネットワークレイヤーの新旧,スリープなど,そもそも19813ソケットが無効になってしまう原因を探ることのほうが重要です。
検証が必要ですが,不安定なネットワークが折り込み済みの環境(移動中にノートパソコンを閉じたり開いたりするなど)であれば,19813通信とは別の経路でサーバーをpingできるかもしれません。
後者の場合,再起動しても接続する相手がいないという問題が残りますが,サーバー自体も自動的に復旧するのであれば,やってみる価値はあるかもしれません。前者の場合,ルーターやタイムアウトの設定(データベースパラメーター#54),ネットワークレイヤーの新旧,スリープなど,そもそも19813ソケットが無効になってしまう原因を探ることのほうが重要です。
検証が必要ですが,不安定なネットワークが折り込み済みの環境(移動中にノートパソコンを閉じたり開いたりするなど)であれば,19813通信とは別の経路でサーバーをpingできるかもしれません。
miyako- 投稿数 : 487
登録日 : 2016/07/05
Re: [v18]「このプロセスの接続は中断されたか、実行できませんでした」
コメントありがとうございます。
エラー発生時、サーバーは正常に稼働していたので、ネットワーク障害の可能性が高いと思います。
発生した端末はノートPCで有線LAN接続、置いたままなので何故発生したのか不明です。
・ルーターの設定 → 調査が難しそうです。(ファイアウォールがアイドルなソケットを閉じてしまった?)
・タイムアウトの設定 → デフォルト(20秒?)です。
・ネットワークレイヤー → サーバーの設定で「旧式ネットワークレイヤーを使用する」にチェックがないので「新」ということでしょうか。
・スリープ → これはWindowsの設定で無効になっていました。
過去のTipsなども見てみましたが、どのように解決できるか分からず困っています。
https://kb.4d-japan.com/Tips/2246/
https://kb.4d-japan.com/Tips/2187/
https://4d-jp.github.io/2019/10/23/idle-connection-timeout/
クライアント側で「SET DATABASE PARAMETER 54番」で秒数を変更して検証する感じでしょうか。
基本的にサーバーに繋がって待機できてればOKなのですが、このエラーイベントを検知して、自動で再起動させるのは難しいでしょうか。
エラー発生時、サーバーは正常に稼働していたので、ネットワーク障害の可能性が高いと思います。
発生した端末はノートPCで有線LAN接続、置いたままなので何故発生したのか不明です。
・ルーターの設定 → 調査が難しそうです。(ファイアウォールがアイドルなソケットを閉じてしまった?)
・タイムアウトの設定 → デフォルト(20秒?)です。
・ネットワークレイヤー → サーバーの設定で「旧式ネットワークレイヤーを使用する」にチェックがないので「新」ということでしょうか。
・スリープ → これはWindowsの設定で無効になっていました。
過去のTipsなども見てみましたが、どのように解決できるか分からず困っています。
https://kb.4d-japan.com/Tips/2246/
https://kb.4d-japan.com/Tips/2187/
https://4d-jp.github.io/2019/10/23/idle-connection-timeout/
クライアント側で「SET DATABASE PARAMETER 54番」で秒数を変更して検証する感じでしょうか。
基本的にサーバーに繋がって待機できてればOKなのですが、このエラーイベントを検知して、自動で再起動させるのは難しいでしょうか。
Ota- 投稿数 : 18
登録日 : 2016/07/22
Re: [v18]「このプロセスの接続は中断されたか、実行できませんでした」
> エラーイベントを検知して、自動で再起動させるのは難しい
エラーが発生した場合,クライアント/サーバー通信の基盤が失われ,プロセス・変数・カレントセレクション・レコードといった同期データが全面的に信頼できない状態なので,メソッドを実行したりフォームを表示したりすることも難しいと思います。それくらい深刻なエラーです。
理論的には,データベースパラメーターを19秒以下にする,あるいは逆にCurrent time(*)を数秒に1回コールするなど,アイドル状態を作らないことでソケットが閉じられてしまうことを防止できるはずです(v2004以前の4Dがそうでした)。
また,データベース設定でCPU優先率がカスタム設定にされている場合,初期設定に戻すことが勧められています。
アプリケーションの内容によっては,旧式レイヤーのほうが効率的なこともあります。その場合,クライアント/サーバ接続のタイムアウトを設定することができ,一定の間隔で「生存確認」が実行されることになります。
それとは別に2分毎のリソースフォルダー同期がありますが,これが接続エラーに関係するという事例はこれまで確認されていません。
エラーが発生した場合,クライアント/サーバー通信の基盤が失われ,プロセス・変数・カレントセレクション・レコードといった同期データが全面的に信頼できない状態なので,メソッドを実行したりフォームを表示したりすることも難しいと思います。それくらい深刻なエラーです。
理論的には,データベースパラメーターを19秒以下にする,あるいは逆にCurrent time(*)を数秒に1回コールするなど,アイドル状態を作らないことでソケットが閉じられてしまうことを防止できるはずです(v2004以前の4Dがそうでした)。
また,データベース設定でCPU優先率がカスタム設定にされている場合,初期設定に戻すことが勧められています。
アプリケーションの内容によっては,旧式レイヤーのほうが効率的なこともあります。その場合,クライアント/サーバ接続のタイムアウトを設定することができ,一定の間隔で「生存確認」が実行されることになります。
それとは別に2分毎のリソースフォルダー同期がありますが,これが接続エラーに関係するという事例はこれまで確認されていません。
miyako- 投稿数 : 487
登録日 : 2016/07/05
Re: [v18]「このプロセスの接続は中断されたか、実行できませんでした」
早々に頂き回答ありがとうございます。
CPU優先度や旧式レイヤー、リソースフォルダー同期についても情報ありがとうございます。
頻繫に起きる現象ではないはずなので、
まずはクライアント側でCurrent time(*)をコールする処理を常駐させようと思います。
CPU優先度や旧式レイヤー、リソースフォルダー同期についても情報ありがとうございます。
頻繫に起きる現象ではないはずなので、
まずはクライアント側でCurrent time(*)をコールする処理を常駐させようと思います。
Ota- 投稿数 : 18
登録日 : 2016/07/22
Permissions in this forum:
返信投稿: 不可