[
https://issues.apache.org/jira/browse/BEAM-13693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17479506#comment-17479506
]
Kenneth Knowles commented on BEAM-13693:
----------------------------------------
Yes. I always want to bump the timeout, unless it is catching a runaway
process. The purpose isn't to constrain run times or resources, but only to
catch runaway processes.
That said, we should probably start to prioritize some work to get
order-of-magnitude reduction in runtime, like merging test pipelines (now I
know the cool epidemiology name for it is "pool testing") or increasing
parallelism (which I expect is constrained to avoid blowing quotas).
I wonder if disaggregating the tests into per-primitive suites would improve
caching, too. (so "ParDo" spec tests would rarely change - they'd still all be
one Jenkins job)
> beam_PostCommit_Java_ValidatesRunner_Dataflow_Streaming timing out at 9 hours
> -----------------------------------------------------------------------------
>
> Key: BEAM-13693
> URL: https://issues.apache.org/jira/browse/BEAM-13693
> Project: Beam
> Issue Type: Bug
> Components: runner-dataflow, test-failures
> Reporter: Brian Hulette
> Assignee: Kenneth Knowles
> Priority: P1
> Labels: currently-failing
>
> This suite started timing out at
> https://ci-beam.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Dataflow_Streaming/1790/
> That build includes the bom update which seems like a likely culprit, but
> note that previous non-cached runs were taking 8h55m (e.g.
> https://ci-beam.apache.org/job/beam_PostCommit_Java_ValidatesRunner_Dataflow_Streaming/1784/),
> so we were already cutting it close.
> [~kenn] do you want to just bump up the timeout further?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
