У меня есть система, которая кэширует крошечные/простые результаты вызова SOAP при запуске
Мне нужны экземпляры, чтобы перезагрузить их кеш при запуске (в случае, если служба SOAP мертва) и ТАКЖЕ обрабатывают возможность использования нескольких экземпляров с использованием этого файла кэша
Я выбрал использовать java.util.prefs, но встроенный в автоматическую синхронизацию поток Java прерывается с ошибкой (1% времени с использованием синхронизации хранилища по умолчанию JVM 30s), сбрасывая следующее исключение:
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, которые используют этот Backing Store, хотя это, похоже, не происходит на наших других машинах.
Может ли кто-нибудь подтвердить это? Каковы риски, если таковые имеются?
Если мой подход ошибочен, что я должен использовать в качестве альтернативы?
"Теперь я подозреваю, что это может быть потому, что у нас есть несколько JVM, которые используют этот резервный магазин"
Это может быть абсолютно так! Если две JVM пытаются заблокировать файл в то же самое, то это то, что вы увидите.
Точные данные будут зависеть от типа блокировки, операционной системы и файловой системы.
Возможно, вы захотите попробовать выполнить операцию, которая вызывает это в блоке try/catch, а затем повторить операцию, если она терпит неудачу.
Вместо использования настроек просто используйте любую сериализуемую карту и создайте очень простой класс кеша, который сериализует и десериализует его произвольно генерируемому временному имени файла (имя файла создается при первой инициализации). Поскольку это только кеш, вы можете просто перехватить любые исключения и reset кэш вернуться к своему первоначальному состоянию, когда произойдет исключение, поэтому он будет повторно извлекаться из исходного источника данных (в случае с SOAP-службой в вашем случае). Поэтому нет необходимости беспокоиться о serialVersionUID или любом из этих материалов совместимости, если вы этого не хотите.
Я столкнулся с той же проблемой с причалом. Я нашел следующее исправление проблемы.
Добавьте .systemPrefs в каталог JRE и предоставите доступ к пользователю, который запускает процесс, который жалуется.
Как только это будет сделано, перейдите в каталог Jetty и откройте файл start.ini
- Djava.util.prefs.userRoot={user home directory}
- Djava.util.prefs.systemRoot={user home directory}
После завершения добавления этих строк я перезапустил причал и обнаружил, что ошибки не исчезли.