Running in Local Mode

[Nitin Gautam]

Hi

I am running Druid in local mode and start the following 4 nodes
1. Coordinator
2. Broker
3. Historical
4. Overlord.

I can see that the indexing service is using the /tmp directory for creating some file. Since the /tmp gets full soon I was trying to change the path which the indexing service uses. I tried the following in the config for overlord but they dont seem to work

druid.indexer.runner.taskDir=<new_path>
druid.indexer.fork.property.druid.indexer.runner.taskDir=<new_path>
druid.indexer.fork.property.druid.indexer.task.baseDir=<new_path>
druid.indexer.fork.property.druid.indexer.task.baseTaskDir=<new_path>

Is there something else that needs to be set.

Thanks
Nitin

[Nitin Gautam]

Hi

I was able to solve the below mentioned problem. However while indexing data I got the following exception once.

java.lang.RuntimeException: java.util.concurrent.ExecutionException: org.jboss.netty.handler.timeout.ReadTimeoutException
        at com.google.common.base.Throwables.propagate(Throwables.java:160)
        at io.druid.indexing.common.actions.RemoteTaskActionClient.submit(RemoteTaskActionClient.java:97)
        at io.druid.indexing.common.TaskToolbox.pushSegments(TaskToolbox.java:204)
        at io.druid.indexing.common.task.IndexTask.run(IndexTask.java:168)
        at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:216)
        at io.druid.indexing.overlord.ThreadPoolTaskRunner$ThreadPoolTaskRunnerCallable.call(ThreadPoolTaskRunner.java:195)
        at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
        at java.util.concurrent.FutureTask.run(FutureTask.java:166)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
        at java.lang.Thread.run(Thread.java:722)
Caused by: java.util.concurrent.ExecutionException: org.jboss.netty.handler.timeout.ReadTimeoutException
        at com.google.common.util.concurrent.AbstractFuture$Sync.getValue(AbstractFuture.java:306)
        at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:293)
        at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116)
        at io.druid.indexing.common.actions.RemoteTaskActionClient.submit(RemoteTaskActionClient.java:90)
        ... 9 more
Caused by: org.jboss.netty.handler.timeout.ReadTimeoutException
        at org.jboss.netty.handler.timeout.ReadTimeoutHandler.<clinit>(ReadTimeoutHandler.java:84)
        at com.metamx.http.client.HttpClient.go(HttpClient.java:254)
        at com.metamx.http.client.RequestBuilder.go(RequestBuilder.java:141)
        at io.druid.indexing.common.actions.RemoteTaskActionClient.submit(RemoteTaskActionClient.java:90)
        at io.druid.indexing.common.task.AbstractFixedIntervalTask.isReady(AbstractFixedIntervalTask.java:69)
        at io.druid.indexing.worker.executor.ExecutorLifecycle.start(ExecutorLifecycle.java:122)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

Any tips of what could be wrong.

Regards
Nitin

[Gian Merlino]

There should be an automatic retry for network timeouts. If it got retried and the second try succeeded, it might have just been a temporary network problem.

[Nitin Gautam]

Thanks I guess what you said is right. When I checked the segments table later I could see the segment table count increased by 1 which meant that the task went throug fine.

Regards

Nitin