You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@samza.apache.org by "Jake Maes (JIRA)" <ji...@apache.org> on 2018/04/23 16:37:00 UTC

[jira] [Created] (SAMZA-1680) There should be no TaskCallbackTimeoutException for StreamTask jobs.

Jake Maes created SAMZA-1680:
--------------------------------

             Summary: There should be no TaskCallbackTimeoutException for StreamTask jobs.
                 Key: SAMZA-1680
                 URL: https://issues.apache.org/jira/browse/SAMZA-1680
             Project: Samza
          Issue Type: Bug
            Reporter: Jake Maes


I have a job that’s throwing the following error:
{noFormat}
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
{noFormat}

However, there's nothing wrong with the application. 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 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 timeout. It should be INT_MAX for StreamTasks



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)