Hung \java.io.FileInputStream.open(原生方法)\ NFS服务器

Question

我们有四个lpars，每个运行一个java实例。

它们对共享的NFS服务器执行大量读/写操作。当NFS服务器突然关闭时，所有试图在这四台服务器中读取映像的线程都会进入挂起状态。

下面的跟踪显示了相同的内容(进程是websphere applciation服务器进程)

1. 当我们处理NFS服务器端的问题时，有什么方法可以避免代码端出现这种情况呢？
2. 如果底层连接是基于tcp的(我假设是这样的)，那么tcp读取/连接超时应该处理这个问题吗？基本上，我希望线程返回到池中，而不是无限地等待对方回复。
3. 还是应该由源机器上的nfs‘客户端’来处理呢？有关nfs的客户端配置设置(因为FileInputStream.open不知道它要读取的文件是在本地服务器上还是在nfs服务器中的共享文件夹上)

预先谢谢你的回答:)

我们用的是

java 1.6 on WAS 7.0

8/2/15 19:52:41:219 GST 00000023 ThreadMonitor W WSVR0605W:线程"WebContainer : 77“(00003c2b)已激活763879毫秒，并可能挂起。服务器中总共有/有110个线程可以挂起。在java.io.FileInputStream.(FileInputStream.java:113) at java.io.FileInputStream.(FileInputStream.java:73) at org.emarapay.presentation.common.util.ImageServlet.processRequest(Unknown Source)在org.emarapay.presentation.common.util.ImageServlet.doGet(Unknown Source)在javax.servlet.http.HttpServlet.service(HttpServlet.java:718)在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( 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

检查此解决方案https://stackoverflow.com/a/9832633/1609655

你可以做一些类似的事情来读取图像。基本上，将调用包装为在Java实现中读取，并在指定的时间内操作未完成时发出线程终止信号。

这可能不是完美的，但我至少会防止您的服务器永远卡住。

Answer 2

这是服务器故障中的“shodanshok”的回应，它帮助了我们。

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

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

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

来源: Linux nfs手册页

Answer 3

http://martinfowler.com/bliki/CircuitBreaker.html

这似乎是这个问题的完美解决方案(以及类似的解决方案)。其思想是将调用包装在另一个对象中，这将阻止对失败服务的进一步调用(基于如何设计此对象来处理情况)。

例如，当外部服务变得没有响应时，线程慢慢进入挂起状态。相反，如果我们有一个阈值LEVLE来阻止线程进入这种状态，那将是很好的。如果我们可以配置，如果外部服务没有响应或者等待响应之前的30个请求，就不要尝试连接到外部服务！在这种情况下，31请求将直接向试图访问报表的客户抛出错误(或向团队发送错误邮件)，但至少第31线程不会被卡在等待中，而是将用于服务器来自其他功能的其他请求。

参考文献：

http://martinfowler.com/bliki/CircuitBreaker.html

http://doc.akka.io/docs/akka/snapshot/common/circuitbreaker.html

http://techblog.netflix.com/2011/12/making-netflix-api-more-resilient.html

https://github.com/Netflix/Hystrix