私はサーバーアプリケーションを持っていますが、これはやや単純化されており、十分ではないサーバーからrest-apiを介して定期的に測定を行います。値はローカルにキャッシュする必要があります (タイムスタンプ付き/不変)。おそらく、すべての位置が測定サンプルに対応するFloatBufferとして格納されます。次の図のように、定期的に ajax リクエストを作成してウェブページの統計情報を更新するウェブブラウザ アプリケーションがあります。
サーバーが稼働していると仮定すると、エラーが発生する可能性のある場所はまだたくさんあります
- REST 測定サーバーに到達できない可能性があります (サーバーが測定値をローカルに保存し続ける場合)。
- 測定サーバーへのネットワーク接続がダウンしている可能性があります
- ストレージがいっぱいか、何らかの理由で破損している可能性があります
- ブラウザがサーバーとの接続を失い、再度接続を試みる可能性があります
一般的にエラーに対処するための私の戦略は次のとおりです。
REST を介して測定サービスから値を取得する際に問題がある場合は、毎分再試行する必要があります。エラーが 30 分以上続く場合は、管理者に通知する必要があります。ディスクに問題が発生した場合は、すぐに管理者に通知するか、できればディスクがいっぱいになる前に通知する必要があります。
エンド ユーザー エクスペリエンスはエラーに対して可能な限り透過的である必要がありますが、エラーが発生したことをユーザーに通知するだけでなく、利用可能な最新のデータを表示することにより、アプリケーションは可能な限り正常に機能する必要があります。
ネットワークの問題 (ジョブによってトリガーされたエージェントを介してclj-httpScheduledThreadPoolExecutorを使用して REST 要求を行う) および をフラッシュしようとしたときのディスクの問題に関して、どのエラーに対処すればよいFloatBufferですか?
上記の非常にステートフルでありながらアルゴリズム的な戦略を実装するための適切な方法は何ですか? エラーが報告されたときにエラーを処理し、agent何らかの復旧モードのジョブに切り替える必要がありますか?