Spark Streaming, Kafka receiver, “Failed to get records for ... after polling for 512“

java.lang.AssertionError: assertion failed: Failed to get records for (...) after polling for 512
使用spark streaming处理kafka中的数据，调试过程中，由于程序停了很长时间，导致kafka中挤压了很多数据，再次启动时，遇到了这个报错。
网上查了很多资料，尝试了很多参数设置，发现然并卵。最后在spark的jira查到了原因。

jira上的原文是：
"If your Spark batch duration is larger than the default Kafka heartbeat session timeout (30 seconds), increase heartbeat.interval.ms and session.timeout.ms appropriately

意思是说：你的spark中的一个batch处理时间（注意是batch中数据的处理时间，不是一个batch的窗口时间，我的batch窗口时间是5s，但由于kafka挤压了很多数据，所以处理时间要几分钟）大于kafka的session的默认心跳时间（30s），导致连接断掉。jira给出的方法是增大kafka的心跳时间。
个人觉得此方法可行，但不是特别好。

前几天，看kafka的文档发现类似问题的描述：
For use cases where message processing time varies unpredictably, neither of these options may be viable. The recommended way to handle these cases is to move message processing to another thread, which allows the consumer to continue sending heartbeats while the processor is still working.
意思是当消息的处理时间不确定时，推荐的方法是将消息处理程序放在一个单独的线程中去处理，这样消费组就可以继续发送心跳，保持连接，同时数据在持续处理。
个人觉得第二种方式更好一点，不用改变默认参数设置，并且通用。

但是，采用第二种方法的时候需要注意：
Some care must be taken to ensure that committed offsets do not get ahead of the actual position. Typically, you must disable automatic commits and manually commit processed offsets for records only after the thread has finished handling them (depending on the delivery semantics you need). Note also that you will generally need to pause(Collection) the partition so that no new records are received from poll until after thread has finished handling those previously returned.

你要小心确保你提交的offset不会大于实际消费的offset。因为你另起线程去处理数据，当自动提交offset的时候，你的数据不一定处理完，你也不能保证你的数据处理成功。所以，
首先，关闭自动提交offset；
其次，只有当你的线程中的数据处理完以后，才能手动提交offset。