0

完了までに約 5 時間かかる groovy スクリプトがあります (多くのワークフローを再起動 (古いものを削除して新しいものを開始) します)。グルーヴィーな呼び出し。

今できることは、ログを確認して Groovy スクリプトを再起動し、問題のあるワークフロー ID を除外することだけです。

この「内部サーバー エラー」をハックでキャッチし、skript を中止する代わりに 次のワークフローを続行できれば、パフォーマンスが大幅に向上します。

すでにtry/catchに入れようとしましたが、うまくいきません。

「内部サーバー エラー」 - 処理するリストのエントリを「無視」する機会はありますか?

助けてくれてありがとう！

4

2 に答える 2

0

私の短い答えは次のとおりです。時間のかかるプロセスにスクリプトを使用しないでください。

標準スクリプトを定義することはできないとおっしゃいましたが、ビジネスは並行して動作しているため、この方法でライブ システムを維持することはお勧めできません。

そのロジックをカスタム CronJobに統合し、すべての構成可能/動的なものをそのジョブのプロパティとして追加します。

このアプローチの利点は、

  • 適切なロギング メカニズムがある (HAC Groovy コンソール sux の Sysout)
  • 実行を追跡できます（消費時間、開始、停止など）
  • 自動的に (CronJob トリガー)、または他の指示されたユーザーによって (操作など) トリガーできます。
  • 全体としてより安定したワークフローが得られます (つまり、これらのマジック スクリプトを追跡する必要はありません (リソース フォルダーでそれらをどのようにバージョン管理しますか?))。

これの欠点は、確かにredeploy が必要なことです。

私の経験から、動的に変更されたコード (例として動的 Bean) は、比較的複雑度の低いプロジェクトで機能しますが、すぐに乱雑になる傾向があります。

于 2015-01-29T12:27:47.503 に答える