[jira] [Work logged] (GOBBLIN-2085) Increase `startToCloseTimeout` for `ExecuteGobblinWorkflow` activities

["ASF GitHub Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GOBBLIN-2085?focusedWorklogId=923063&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-923063 ]

ASF GitHub Bot logged work on GOBBLIN-2085:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 12/Jun/24 02:47
            Start Date: 12/Jun/24 02:47
    Worklog Time Spent: 10m 
      Work Description: phet opened a new pull request, #3970:
URL: https://github.com/apache/gobblin/pull/3970

   
   
   Dear Gobblin maintainers,
   
   Please accept this PR. I understand that it will not be reviewed until I have checked off all the steps below!
   
   
   ### JIRA
   - [ ] My PR addresses the following [Gobblin JIRA](https://issues.apache.org/jira/browse/GOBBLIN/) issues and references them in the PR title. For example, "[GOBBLIN-XXX] My Gobblin PR"
       - https://issues.apache.org/jira/browse/GOBBLIN-2085
   
   
   ### Description
   - [ ] Here are some details about my PR, including screenshots (if applicable):
   
   the currently hard-coded `startToCloseTimeout` values are too short.  upon gaining operational experience, these requirements have come into focus:
   
   * `ProcessWorkUnits` must support extractors utilizing little parallelism (such as those reading from a DB) that take a very long time, even upwards of hours
   * `CommitActivity` runs may have to handle O(10k) or more task state files, which may take a long time to open and read, esp. when the `FileSystem` is under heavy load
   * `GenerateWorkUnits` must work with sources that may be quite vast, yet w/ limited recourse to parallelism, such as a massive source iceberg
   
   ideally these and other temporal config values would be configurable.  that will come soon!  for now, bump to values large enough to resolve site-up concerns.
   
   ### Tests
   - [ ] My PR adds the following unit tests __OR__ does not need testing for this extremely good reason:
   
   ```
   ./gradlew build
   ```
   
   ### Commits
   - [ ] My commits all reference JIRA issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "[How to write a good git commit message](http://chris.beams.io/posts/git-commit/)":
       1. Subject is separated from body by a blank line
       2. Subject is limited to 50 characters
       3. Subject does not end with a period
       4. Subject uses the imperative mood ("add", not "adding")
       5. Body wraps at 72 characters
       6. Body explains "what" and "why", not "how"
   
   




Issue Time Tracking
-------------------

            Worklog Id:     (was: 923063)
    Remaining Estimate: 0h
            Time Spent: 10m

> Increase `startToCloseTimeout` for `ExecuteGobblinWorkflow` activities
> ----------------------------------------------------------------------
>
>                 Key: GOBBLIN-2085
>                 URL: https://issues.apache.org/jira/browse/GOBBLIN-2085
>             Project: Apache Gobblin
>          Issue Type: Bug
>          Components: gobblin-core
>            Reporter: Kip Kohn
>            Assignee: Abhishek Tiwari
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> the currently hard-coded `startToCloseTimeout` values are too short.  requirements that have come to light w/ operational experience:
> * `ProcessWorkUnits` must support extractors utilizing little parallelism (such as those reading from a DB) that take a very long time, even upwards of hours
> * `CommitActivity` runs may have to handle O(10k) or more task state files, which may take a long time to open and read, esp. when the `FileSystem` is under heavy load
> * `GenerateWorkUnits` must work with sources that may be quite vast, yet w/ limited recourse to parallelism, such as a massive source iceberg
> ultimately these and other temporal config values would ideally be configurable, and that will come soon.  for now, just bump to values large enough to resolve site-up issues.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)