【转载】Storm TickTuple 意外停止

原文链接转自：http://woodding2008.iteye.com/blog/2328114

Storm的滑动窗口TickTuple通常用来控制bolt定制执行入库操作，使用过程中遇到了TickTuple“意外停止”的情况。

场景描述

Jiaodian任务共计使用12个worker，tick tuple间隔为5分钟。

WebPvLogSpout & WebPvLogBolt的executor数量为12.

WebPvLogSpout消费kafka topic,log_product_ypvlog共计10个partition

6月14号下午启动，次日凌晨1点35分之后,有2个bolt就收不到tick tuple。

生产tickTuple消息的线程【user-timer】由于disruptor的原因，一直处于挂起状态。

1. "user-timer" daemon prio=10 tid=0x00007f8ea8ac7000 nid=0x353c runnable [0x00007f8e29662000]
2. java.lang.Thread.State: TIMED_WAITING (parking)【处于挂起状态，一致等待信号激活自己，正常情况应该处于sleeping状态】
3. at sun.misc.Unsafe.park(Native Method)
4. at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:349)
5. at com.lmax.disruptor.AbstractMultithreadedClaimStrategy.waitForFreeSlotAt(AbstractMultithreadedClaimStrategy.java:99)
6. at com.lmax.disruptor.AbstractMultithreadedClaimStrategy.incrementAndGet(AbstractMultithreadedClaimStrategy.java:49)
7. at com.lmax.disruptor.Sequencer.next(Sequencer.java:127)
8. at backtype.storm.utils.DisruptorQueue.publishDirect(DisruptorQueue.java:174)
9. at backtype.storm.utils.DisruptorQueue.publish(DisruptorQueue.java:167)
10. at backtype.storm.disruptor$publish.invoke(disruptor.clj:66)
11. at backtype.storm.disruptor$publish.invoke(disruptor.clj:68)
12. at backtype.storm.daemon.executor$setup_ticks_BANG_$fn__6510.invoke(executor.clj:315)
13. at backtype.storm.timer$schedule_recurring$this__1807.invoke(timer.clj:99)
14. at backtype.storm.timer$mk_timer$fn__1790$fn__1791.invoke(timer.clj:50)
15. at backtype.storm.timer$mk_timer$fn__1790.invoke(timer.clj:42)
16. at clojure.lang.AFn.run(AFn.java:24)
17. at java.lang.Thread.run(Thread.java:745)

问题分析

包装后的kafka客户端会让分配不到partition的spout一直阻塞[ArrayBlockingQueue.take()]

user-timer多个小时的jstack信息，都是TIMED_WAITING (parking)，其他worker的状态是sleeping。

spout几个小时一直阻塞，由于spout接收队列会被metrics and system stream塞满，一直得不到处理，会导致TickTuple消息无法放入到队列，这就导致了user-timer线程一直挂起，等待被唤醒。

解决方案

将spout的数量设置为kafka topic的partition相等的数量，实际上是不让spout长时间的处于阻塞状态。

官网issues