NFS服务器/洪线程

Question

我们有四个lpars，每个运行一个java实例。它们对共享的NFS服务器执行大量读/写操作。当NFS服务器突然关闭时，所有试图在这四台服务器中读取图像的线程都会进入挂起状态。下面的跟踪显示了相同的内容(进程是websphere applciation服务器进程)

1)当我们处理NFS服务器端的问题时，有没有办法避免代码端出现这种情况？

2)如果底层连接是基于tcp的(我假设是这样的)，那么tcp读取/连接超时应该处理这个问题吗？基本上，我希望线程返回到池中，而不是无限地等待对方回复。

3)或者这是源机器上的nfs‘客户’应该注意的事情吗？有关nfs的客户端配置设置(因为FileInputStream.open不知道它要读取的文件是在本地服务器上还是在nfs服务器中的共享文件夹上)

预先谢谢你的回答:)

我们在WAS7.0上使用java 1.6

[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

Answer 1

这可能取决于NFS共享是如何挂载的。默认情况下，NFS共享是使用“硬”参数挂载的，这意味着对未响应的NFS共享的访问将无限期地阻塞。

您可以更改客户端挂载点，添加以下参数之一(我在这里使用Linux手册页，可能您的特定选项略有不同)：

• 软:如果指定了软选项，则NFS客户端在重新传输发送后失败NFS请求，从而导致NFS客户端向调用应用程序返回错误。
• intr:选择是否允许信号中断这个挂载点上的文件操作。使用intr选项比使用软选项更可取，因为它导致数据损坏的可能性要小得多。FYI，这在Linux内核2.6.25+中被否决了。

来源: Linux nfs手册页