Task Execute Timing out

[chthroop]

Hi,
We are using the cloudplex version of Snaplogic. We have a pipeline built that downloads a very large weather data set. We had to build the pipeline to execute in “batches” using the Task Execute snap because the 100mm row+ download files up the temp file space if we do all in one go…

I am getting timeouts after 15 minutes and would like to either up that timeout parameter or make it so that the parent pipeline doesn’t think the task pipeline has timed out. I was told that having an “open view” in the task pipeline would keep the parent from thinking a timeout has happened but this isn’t working.

Any ideas? thanks

[tstack]

chthroop:

Tim - our testing shows that the PipelineExec loads all children to one node.

Are you referring to some executions in the attached screenshot? I took a look at the first set of STOPPED triggered executions in the screenshot and they were all scheduled to the same node because the other node in the Snaplex had reached its maximum memory usage limit. Therefore, the scheduler would not treat the other node as a possible candidate for running new executions.

chthroop:

To Chris’ point, I would think that another setting should be “multi-node” where you can specific whether you want the child pipelines spread across multiple nodes or not. I would imagine that multi-node would require a bit more communications between nodes, but would create better utilization

You can specify that by setting the Snaplex property in PipeExec. The simplest way to get it to run on the same Snaplex as the parent is to make it an expression and set the value to pipe.plexPath. But, it depends on the resource usage of the nodes and it tends to prefer the local node.

If you’re interested in trying another configuration, I think I made a mistake above in recommending to use Reuse with PipeExec. With Reuse disabled, a new child execution will be started for each location and a new scheduling decision will be made. Since the children run for awhile and consume quite a few resources, the scheduler should have more data to make a better decision on where to execute the child. (Enabling Reuse would help to avoid the overhead of starting a new execution, but that’s not very relevant here since every location results in a lot of work being done.) Maybe try setting the pool size to 10 or 20 to start with and then dial it in after some testing.