You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@gobblin.apache.org by "ASF GitHub Bot (Jira)" <ji...@apache.org> on 2022/03/18 21:08:00 UTC

[jira] [Work logged] (GOBBLIN-1624) Gobblin as a Service does not emit correct running job metrics and quotas in some edge cases

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

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

                Author: ASF GitHub Bot
            Created on: 18/Mar/22 21:07
            Start Date: 18/Mar/22 21:07
    Worklog Time Spent: 10m 
      Work Description: Will-Lo opened a new pull request #3481:
URL: https://github.com/apache/gobblin/pull/3481


   …jobs
   
   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
   - [x] 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-1624
   
   
   ### Description
   - [x] Here are some details about my PR, including screenshots (if applicable):
   With the DagManager class in GaaS, during rollout/leader swap it is possible to get an inaccurate count of running jobs emitted, and quotas for these running jobs.
   
   For example, if the leader is shut down while keeping track of 10 running jobs, and during restart 5 of these jobs completed, the leader would emit that 0 jobs are currently running since it would not treat the job counters as idempotent. Additionally, we over-decrement due to not differentiating jobs running on the executor that fail, vs jobs that fail on the GaaS side.
   
   We should keep track of currently running jobs better to ensure that we only decrement counters/quotas for jobs that are actually running on the executor and track better between startup. 
   
   ### Tests
   - [x] My PR adds the following unit tests __OR__ does not need testing for this extremely good reason:
   Added tests in the DagManagerTest class, will expand tests to the QuotaManager once functionality expands
   
   ### Commits
   - [x] 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"
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@gobblin.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


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

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

> Gobblin as a Service does not emit correct running job metrics and quotas in some edge cases
> --------------------------------------------------------------------------------------------
>
>                 Key: GOBBLIN-1624
>                 URL: https://issues.apache.org/jira/browse/GOBBLIN-1624
>             Project: Apache Gobblin
>          Issue Type: Task
>            Reporter: William Lo
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> With the DagManager class in GaaS, during rollout/leader swap it is possible to get an inaccurate count of running jobs emitted, and quotas for these running jobs.
> For example, if the leader is shut down while keeping track of 10 running jobs, and during restart 5 of these jobs completed, the leader would emit that 0 jobs are currently running since it would not treat the job counters as idempotent. Additionally, we over-decrement due to not differentiating jobs running on the executor that fail, vs jobs that fail on the GaaS side.
> We should keep track of currently running jobs better to ensure that we only decrement counters/quotas for jobs that are actually running on the executor and track better between startup. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)