Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Won't Fix
-
None
-
None
-
None
-
None
Description
I have a job that’s throwing the following error:
org.apache.samza.task.TaskCallbackTimeoutException: Task Partition 0 callback times out at org.apache.samza.task.TaskCallbackManager$1.run(TaskCallbackManager.java:101) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) 2018-04-22 22:35:36 AsyncRunLoop [ERROR] Got callback failure for task Partition 0
However, there's nothing wrong with the job. I’m doing a data purge from the RocksDB store in process() and it’s taking longer than the timeout. So the job is a bit unusual, but there’s no bug (e.g. a hang) causing the timeout… it’s just taking a long time.
It's pretty unintuitive for StreamTask (as opposed to AsyncStreamTask) jobs to have to configure a higher timeout for a callback that they aren't responsible for (it's handled by the framework). The timeout should be INT_MAX for StreamTasks
Attachments
Issue Links
- duplicates
-
-
- Open
-