1

私はDFS Java APIを使用していますが、たとえば、サービスコンテキストで構成できるサービス呼び出しのクライアント側タイムアウトを構成する簡単な方法を誰かが知っているかどうか疑問に思っていましたか?

Documentum リポジトリが応答しないというまれな状況を経験しました。そのため、すべての DFS 呼び出しに対して一般的なタイムアウトを検討しています。

ハングしているサービス コールをテストするために、ドキュメントを更新するときにスレッドを 10 分間ブロックするダミーの TBO 実装を作成しました。

@Override
 public void saveEx(boolean keepLock, String versionLabels) throws DfException {
  if (isNew() == false) {
    try {
      Thread.sleep(1000*60*10);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
  super.saveEx(keepLock, versionLabels);
}

これがハングしたサービス コールとまったく同じように動作するかどうかはわかりませんが、少なくとも私のテストでは期待どおりに動作しました。オブジェクト サービスのupdateメソッドの呼び出しには約 10 分かかりました。

まだ見つかっていない構成がありますか、それともタイムアウトを構成するためにサービス コンテキストに渡すランタイム プロパティがありますか?

これには、独自のメカニズムを実装するのではなく、DFS の既存の機能を使用することをお勧めします。

4

1 に答える 1

0

で値を編集してみましたdfs-runtime.propertiesか？タイムアウトがコンテキスト固有である可能性はないと思いますが、クライアント全体でタイムアウトを変更できるはずです。

https://community.emc.com/message/3249#3249から再投稿

「導入ガイドのサーバーランタイム起動設定のセクションを参照してください。

次のリストは、dfs-runtime.propertiesファイルの場所に応じてファイルが優先する優先順位を示しています。

  1. local-dfs‑runtime.propertiesローカルクラスパスのファイル
  2. で指定されたランタイムプロパティファイル‑Ddfs.runtime.properties.file
  3. dfs‑runtime.propertiesでパッケージ化emc‑dfs‑rt.jar

たとえば、ローカルクラスパスのsファイルの設定は、にあるファイルまたはパラメータで指定されたファイルlocal-dfs‑runtime.propertieの同じ設定よりも優先されます。構成を変更した後は、DFSアプリケーションを再起動する必要があります。ベストプラクティスとして、基本設定のファイルにデプロイされている提供された構成ファイルを使用し、外部ファイルを使用して、特に変更したい設定を上書きします。」dfs‑runtime.propertiesemc‑dfs‑rt.jar‑Demc‑dfs‑rt.jar

于 2013-02-14T20:13:03.687 に答える