21

起動時の SOAP 呼び出しの小さな/単純な結果をキャッシュするシステムがあります。

インスタンスが起動時にキャッシュをリロードできるようにする必要があり (SOAP サービスが停止している場合)、このキャッシュ ファイルを使用して複数のインスタンスの可能性を処理することもできます。

使用することを選択しましjava.util.prefsたが、Java の組み込み自動同期スレッドが断続的に失敗し (デフォルトの JVM 30 秒バッキング ストア同期を使用する時間の 1%)、次の例外がダンプされます。

Jan 8, 2010 12:30:07 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.

私はこのバグを疑っていましたが、これは 1.5(tiger-b40) で修正されており、このボックスの Java 5 は "1.5.0_16-b02" です。

複数の JVM がこのバッキング ストアを共有していることが原因ではないかと考えていますが、これは他のマシンでは発生していないようです。

誰でもこれを確認できますか？もしあれば、どのようなリスクがありますか？

私のアプローチに欠陥がある場合、代わりに何を使用すればよいですか?

4

3 に答える 3

11

「このバッキングストアを共有している複数のJVMがあるためだと思います」

これは絶対に当てはまる可能性があります！2つのJVMが同時にファイルをロックしようとすると、これが表示されます。

正確な詳細は、ロックの種類、オペレーティングシステム、およびファイルシステムによって異なります。

これを引き起こす操作をtry/catchブロックでラップしてみて、失敗した場合は操作を再試行することをお勧めします。

于 2010-01-09T21:55:00.157 に答える
1

私は桟橋で同じ問題に遭遇しました。以下が問題を修正したことがわかりました。

JRE ディレクトリにを追加し、.systemPrefs問題のあるプロセスを実行しているユーザーにアクセスを提供します。

それが完了したら、Jetty ディレクトリに移動してstart.iniファイルを開きます。

-Djava.util.prefs.userRoot={user's home directory}

-Djava.util.prefs.systemRoot={user's home directory}

これらの行の追加が完了したら、jetty を再起動したところ、エラーがなくなっていることがわかりました。

于 2014-09-18T22:48:37.527 に答える