Назад | Перейти на главную страницу

Сервер NFS | Висели потоки

У нас есть четыре lpar, каждый из которых запускает по 1 экземпляру java. Они выполняют множество операций чтения / записи на общем сервере NFS. Когда сервер NFS резко выключается, все потоки, которые пытались прочитать изображение на каждом из этих четырех серверов, переходят в состояние зависания. Трассировка ниже показывает то же самое (процесс - это процесс сервера приложения websphere)

1) Пока мы работаем над проблемами на стороне сервера NFS, есть ли способ избежать этого со стороны кода?

2) Если базовое соединение основано на tcp (как я предполагаю), должен ли тайм-аут чтения / подключения tcp позаботиться об этом? В основном я хочу, чтобы поток был возвращен обратно в пул, а не бесконечно ждать ответа другой стороны.

3) Или это то, о чем должен позаботиться клиент nfs на исходной машине? Некоторые настройки конфигурации на стороне клиента, относящиеся к nfs (поскольку FileInputStream.open не будет знать, находится ли файл, который он пытается прочитать, на локальном сервере или в общей папке на сервере nfs)

Заранее спасибо за ответы :)

Мы используем java 1.6 на WAS 7.0

[8/2/15 19:52:41:219 GST] 00000023 ThreadMonitor W   WSVR0605W: Thread "WebContainer : 77" (00003c2b) has been active for 763879 milliseconds and may be hung.  There is/are 110 thread(s) in total in the server that may be hung.
        at java.io.FileInputStream.open(Native Method)
        at java.io.FileInputStream.<init>(FileInputStream.java:113)
        at java.io.FileInputStream.<init>(FileInputStream.java:73)
        at org.emarapay.presentation.common.util.ImageServlet.processRequest(Unknown Source)
        at org.emarapay.presentation.common.util.ImageServlet.doGet(Unknown Source)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:718)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1694)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1635)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:113)
        at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:80)
        at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:908)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:965)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:508)
        at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest(ServletWrapperImpl

Вероятно, это зависит от того, как смонтирован общий ресурс NFS. По умолчанию общие ресурсы NFS монтируются с "жесткими" параметрами, что означает, что доступ к неотвечающему общему ресурсу NFS будет заблокирован на неопределенный срок.

Вы можете изменить точку монтирования на стороне клиента, добавив один из следующих параметров (я использую здесь справочную страницу Linux, возможно, ваши конкретные параметры немного отличаются):

  • soft: если указана мягкая опция, то клиент NFS не выполняет запрос NFS после того, как были отправлены повторные передачи, в результате чего клиент NFS возвращает ошибку вызывающему приложению
  • intr: выбирает, разрешить ли сигналам прерывать файловые операции в этой точке монтирования. Использование параметра intr предпочтительнее, чем использование программного параметра, поскольку оно значительно менее вероятно приведет к повреждению данных. К вашему сведению, это устарело в ядре Linux 2.6.25+

Источник: справочная страница Linux nfs