问题的发现
在In（一个大数据运营管理系统）中创建storm/jstorm/hbase（on slider）集群时都出现页面卡住状态，无法成功创建。而创建storm/jstorm/hbase集群的代码中有一个共同的操作是创建YARN 队列（通过调用ambari rest接口实现），怀疑与此相关，故试了下单独创建一个YARN 队列，果然也出现了页面卡住的状态，等待了一会后chrome浏览器会出现下图所示界面。去ambari web 页面上看了刷新队列操作历史，发现该操作的时间变慢了（50秒左右），从而可以怀疑是刷新队列时间变慢引出该问题。
![fair-op]()
问题修复（第一次）
为了验证上面的猜想，找熟悉ambari相关同事解决了该问题后，可以成功创建storm/jstorm/hbase了。但是，rest接口调用导致页面长时间卡住也是不科学的，为了进一步确认该问题，检查了之前通过jstack pid拿到的信息，如下图红框中所示，创建队列的线程拿着锁进入到TIMED_WAITING（sleeping）状态，其他试图获取该锁的线程都进入到了BLOCKED状态，等待sleeping的线程能够醒来释放锁。既然是TIMED_WAITING状态，那理论上来说一定时间是会醒过来的，由于已经知道是哪部分代码导致的了，看了代码中使用了的是Apache 的HttpClient来发起rest请求，但是未设置超时机制，即便如此也应该会有一个默认超时时间，查看相关资料和代码，httpclient不会添加一个默认超时时间，会按照os的tcp_fin_timeout http 短连接
复现问题
由于ambari同事已被修复了该问题，但为了验证in修复是否有效，需要先复现刷新Fair Scheduler慢的问题，咨询了下相关同事尝试短时间内复现问题未果后，最终通过脚本同时发送大量刷Fair Scheduler命令来延长infinite中的rest调用的时间。ambari中的显示如下：
![refrashyarn]()
此时，在infinite中的界面中进行创建yarn服务的操作（该操作中需要刷新fair scheduler），问题复现了，通过jstack pid拿到线程的堆栈信息，找到我们我感兴趣的线程如下图红框所示，该线程就是会调用rest接口刷新队列的，
![fair-op]()
问题修复（第二次）
通过jstack诊断得知是刷新YARN Fair Scheduler相关方法所导致（详见下图）。由于YARN Fair Scheduler是临界资源故该方法被加了锁（sychronized），该线程拿着锁进入了TIMED_WAITING（sleeping）状态！既然是TIMED_WAITING，该线程应该是会在有限时间内回到RUNNABLE状态的，等了十多分钟后发现该线程依然处于TIMED_WAITING状态，此时已有其他为了获取锁进入了BLOCKED状态（详见下图），大量的线程无法结束，资源得不到释放，可能引发OOM 或 too many open files 错误，也增加了线程的调度的开销。
![fair-jstack1]()
ambari刷新YARN Fair Scheduler速度变慢（可以理解为某个方法调用较慢），在infinite（大数据运营管理系统）中会调用ambari的rest接口刷新fai scheduer，Fair Scheduler 为临界资源，所以为刷新Fair Scheduler的方法加了锁（synchronized），但因为rest接口变慢导致infinite页面卡死显然不合理，猜测是锁未及时释放。
问题探究
通过
解决问题
由于已经定位到了相关用户代码，看了段代码后发现创建的httpclient未设置超时，以为是这个原因导致线程迟迟未能释放同步锁，
http://stackoverflow.com/questions/9734384/default-timeout-for-httpcomponent-client
http://stackoverflow.com/questions/3000214/java-http-client-request-with-defined-timeout
问题的发现
在In（一个大数据运营管理系统）中创建storm/jstorm/hbase（on slider）集群时都出现页面卡住状态，无法成功创建。而创建storm/jstorm/hbase集群的代码中有一个共同的操作是创建YARN 队列（通过调用ambari rest接口实现），怀疑与此相关，故试了下单独创建一个YARN 队列，果然也出现了页面卡住的状态，等待了一会后chrome浏览器会出现下图所示界面。去ambari web 页面上看了刷新队列操作历史，发现该操作的时间变慢了（50秒左右），从而可以怀疑是刷新队列时间变慢引出该问题。
问题修复（第一次）
为了验证上面的猜想，找熟悉ambari相关同事解决了该问题后，可以成功创建storm/jstorm/hbase了。但是，rest接口调用导致页面长时间卡住也是不科学的，为了进一步确认该问题，检查了之前通过jstack pid拿到的信息，如下图红框中所示，创建队列的线程拿着锁进入到TIMED_WAITING（sleeping）状态，其他试图获取该锁的线程都进入到了BLOCKED状态，等待sleeping的线程能够醒来释放锁。既然是TIMED_WAITING状态，那理论上来说一定时间是会醒过来的，由于已经知道是哪部分代码导致的了，看了代码中使用了的是Apache 的HttpClient来发起rest请求，但是未设置超时机制，即便如此也应该会有一个默认超时时间，查看相关资料和代码，httpclient不会添加一个默认超时时间，会按照os的tcp_fin_timeout http 短连接
复现问题
由于ambari同事已被修复了该问题，但为了验证in修复是否有效，需要先复现刷新Fair Scheduler慢的问题，咨询了下相关同事尝试短时间内复现问题未果后，最终通过脚本同时发送大量刷Fair Scheduler命令来延长infinite中的rest调用的时间。ambari中的显示如下：
此时，在infinite中的界面中进行创建yarn服务的操作（该操作中需要刷新fair scheduler），问题复现了，通过jstack pid拿到线程的堆栈信息，找到我们我感兴趣的线程如下图红框所示，该线程就是会调用rest接口刷新队列的，
问题修复（第二次）
通过jstack诊断得知是刷新YARN Fair Scheduler相关方法所导致（详见下图）。由于YARN Fair Scheduler是临界资源故该方法被加了锁（sychronized），该线程拿着锁进入了TIMED_WAITING（sleeping）状态！既然是TIMED_WAITING，该线程应该是会在有限时间内回到RUNNABLE状态的，等了十多分钟后发现该线程依然处于TIMED_WAITING状态，此时已有其他为了获取锁进入了BLOCKED状态（详见下图），大量的线程无法结束，资源得不到释放，可能引发OOM 或 too many open files 错误，也增加了线程的调度的开销。
ambari刷新YARN Fair Scheduler速度变慢（可以理解为某个方法调用较慢），在infinite（大数据运营管理系统）中会调用ambari的rest接口刷新fai scheduer，Fair Scheduler 为临界资源，所以为刷新Fair Scheduler的方法加了锁（synchronized），但因为rest接口变慢导致infinite页面卡死显然不合理，猜测是锁未及时释放。
问题探究
通过
解决问题
由于已经定位到了相关用户代码，看了段代码后发现创建的httpclient未设置超时，以为是这个原因导致线程迟迟未能释放同步锁，