Question

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

他们对共享NFS服务器执行大量读/写操作。当NFS服务器突然中断时，尝试读取这四个服务器中每个服务器中的映像的所有线程都进入挂起状态。

下面的跟踪显示相同的内容（进程是websphere applciation服务器进程）

在我们处理NFS服务器端的问题时，有没有办法从代码端避免这种情况？
如果底层连接是基于tcp的（我假设它是），tcp read / connect timeout是否应该处理这个问题？基本上我想将线程返回到池中，而不是无限期地等待对方响应。
或者这是nfs＆＃39;客户端应该注意的事情。在源机器上？客户端的一些配置设置与nfs有关（因为FileInputStream.open不知道它试图读取的文件是在本地服务器上还是在nfs服务器中的共享文件夹中）

提前感谢您的回答：）

我们正在使用

java 1.6 on WAS 7.0

[8/2/15 19：52：41：219消费税] 00000023 ThreadMonitor W WSVR0605W：线程＆＃34; WebContainer：77＆＃34; （00003c2b）已激活763879毫秒并且可能会被挂起服务器中总共有110个线程那可能是挂的。 at java.io.FileInputStream.open（Native Method）在java.io.FileInputStream。（FileInputStream.java:113）在java.io.FileInputStream。（FileInputStream.java:73）在org.emarapay.presentation.common.util.ImageServlet.processRequest（未知资源）在org.emarapay.presentation.common.util.ImageServlet.doGet（未知资源）在javax.servlet.http.HttpServlet.service（HttpServlet.java:718）在javax.servlet.http.HttpServlet.service（HttpServlet.java:831）在com.ibm.ws.webcontainer.servlet.ServletWrapper.service（ServletWrapper.java:1694）在com.ibm.ws.webcontainer.servlet.ServletWrapper.service（ServletWrapper.java:1635）在com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter（WebAppFilterChain.java:113）在com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter（WebAppFilterChain.java:80）在com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter（WebAppFilterManager.java:908）在com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest（ServletWrapper.java:965）在com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest（ServletWrapper.java:508）在com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.handleRequest（ServletWrapperImpl

Answer 1

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

您可以执行类似的操作来阅读图像。基本上将调用包装在Java Future实现中，并在操作未在指定的时间内完成时发出线程终止信号。

它可能不完美，但我会至少阻止你的服务器永远被困住。

Answer 2

这是@shodanshok在serverfault中的回复，它帮助了我们。

这可能取决于NFS共享的安装方式。默认情况下，NFS共享使用＆＃34; hard＆＃34;参数，意味着访问不响应的NFS共享将无限期地阻塞。

您可以更改客户端安装点，添加以下参数之一（我在这里使用Linux手册页，也许您的具体选项有点不同）：

soft：如果指定了soft选项，则NFS客户端在重新发送重新发送后失败NFS请求，导致NFS客户端向调用applicationintr返回错误：选择是否允许信号中断文件操作这个挂载点。使用intr选项比使用soft选项更受欢迎，因为它不太可能导致数据损坏。仅供参考，这在Linux内核2.6.25 +

中已被弃用

来源：Linux nfs手册页

Answer 3

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

这似乎是这个问题（和类似的）的完美解决方案。我们的想法是将调用包装在另一个对象中，该对象将阻止进一步调用（基于您如何设计此对象来处理该情况）到失败的服务。

E.g。当外部服务无响应时，慢速线程进入挂起状态。相反，如果我们有一个THRESHOLD LEVLE会阻止线程进入该状态会很好。如果我们可以配置说，如果它没有响应或等待响应前30个请求，请不要尝试连接到外部服务！在这种情况下，31请求将直接向尝试访问报告的客户抛出错误（或向团队发送错误邮件）但ATLEAST第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

Hung theads | java.io.FileInputStream.open（Native Method）| NFS服务器

3 个答案: