2013-02-12 11 views
1

Я работаю с API-интерфейсом DFS Java и задаюсь вопросом, знает ли кто-нибудь простой способ настроить тайм-аут на стороне клиента для вызовов служб, которые могут быть настроены в контексте службы, например ?Documentum DFS: таймаут для служебных вызовов

У меня возникли некоторые редкие случаи, когда репозиторий Documentum не отвечал, поэтому я рассматриваю общий тайм-аут для всех вызовов DFS.

Для тестирования вызова висит службу, я создал фиктивную реализацию между переборками, что просто блокирует нить в течение 10 минут при обновлении документа:

@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); 
} 

я не уверен, если это ведет себя так же, как сервис для подвешивания call, но по крайней мере в моих тестах он работал как ожидалось - мои вызовы update метод Служба объектов заняла около 10 минут.

Есть ли какая-либо конфигурация, которую я еще не нашел, или, может быть, свойство runtime-property для перехода в контекст службы для настройки таймаута?

Я бы предпочел использовать существующие функции DFS для этого вместо того, чтобы реализовать свой собственный механизм.

+0

Привет, Флориан, больше обновлений об этом? –

ответ

0

Вы пробовали редактировать значение в dfs-runtime.properties? Я не думаю, что таймаут может быть контекстно-зависимым, но вы должны иметь возможность изменить его для клиента в целом.

Повторно из https://community.emc.com/message/3249#3249

«Пожалуйста, смотрите параметры запуска среды выполнения SERVER раздел руководства по развертыванию

Следующий список описывает преимущество, что dfs-runtime.properties файлы берут в зависимости от их расположения:.

  1. local-dfs‑runtime.properties файл в местных classpath
  2. runtime свойства указанный файл с ‑Ddfs.runtime.properties.file
  3. dfs‑runtime.properties упакованных с emc‑dfs‑rt.jar

Например, настройки в local-dfs‑runtime.propertie сек файла на локальном пути к классам будут иметь приоритет одинаковых настроек в dfs‑runtime.properties файле, который находится в emc‑dfs‑rt.jar или один указанной с параметром ‑D. Приложение DFS должно быть перезапущено после любых изменений конфигурации. В качестве наилучшей практики используйте предоставленный файл конфигурации, который развернут в файле emc‑dfs‑rt.jar для ваших базовых настроек, и используйте внешний файл, чтобы переопределить параметры, которые вы хотите изменить. »

+0

Какое конкретное значение вы имеете в виду? Я провел быстрый тест, установив _dfs.crs.cache_expiration_after_x_minutes_ в 4, в сочетании с настройкой _dfs.crs.perform_cleanup_every_x_minutes_ to 2, но это ничего не меняло. Возможно, это неправильные параметры или мои изменения не были применены должным образом из-за проблем с classpath, мне придется снова это проверить. Однако ваше предложение звучит как общий тайм-аут контекста сессии для меня - это правильно? Это будет означать, когда я запускаю серию сервисов повторное использование контекста, тайм-аут будет применяться к сумме всех вызовов, ri GHT? –

+0

Я нашел это здесь: https: // community.emc.com/message/367828. Попробуйте 'dfs.crs.cache_expiration_after_x_minutes = 60' и ' dfs.crs.perform_cleanup_every_x_minutes = 20' В противном случае у вас может возникнуть проблема с classpath с вашей конфигурацией. –

+0

Извините, я никогда не продолжал заниматься этой темой, и теперь у меня больше нет доступа к соответствующей тестовой системе. –