I have a system that caches the tiny/simple results of an on-startup SOAP call
I need instances to be able to reload their cache on startup (in case the SOAP service is dead) and ALSO handle the possibility of multiple instances using this cache file
I chose to use java.util.prefs
but Java's builtin automatic sync thread is intermittently failing (1% of time using default JVM 30s backing store sync) dumping the following the exception:
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.
I suspected this bug but this was fixed in 1.5(tiger-b40) and our java 5 on this box is "1.5.0_16-b02".
I now suspect that it might be because we have multiple JVMs sharing this Backing Store, although this doesn't seem to happen on our other machines.
Can anyone confirm this? What are the risks, if any?
If my approach is flawed what should I be using as an alternative?
"I now suspect that it might be because we have multiple JVMs sharing this Backing Store"
This could absolutely be the case! If two JVMs attempt to lock the file at the same then this is what you'll see.
The exact details will depend on the type of lock, operating system and file system.
You might want to try wrapping the operation that causes this in a try/catch block, then retry the operation if it fails.
I ran into the same issue with jetty. I found the following fixed the issue.
Add a .systemPrefs
to your JRE directory and provide access to the user who is running the process which is complaining.
Once that is done, go to the Jetty directory and open the start.ini
file
-Djava.util.prefs.userRoot={user's home directory}
-Djava.util.prefs.systemRoot={user's home directory}
Once finished adding those lines I restarted jetty and found that the errors were gone.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With