[
https://issues.apache.org/jira/browse/GOBBLIN-1963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Apekshit Kumar updated GOBBLIN-1963:
------------------------------------
Description:
*Context:*
Following a restart, Gobblin service is currently unable to process previous
jobs in the RUNNING/LAUNCHED/SUBMITTED state, resulting in a stuck state for
these jobs.
*Example scenario mentioned here*
A job is in the LAUNCHED state, and while calculating CDC, the Application
master got re-attempted, actually due to name node issue (can be any env
issues).
!2ac4a7d8-f168-4877-a583-03d62f1384ac.png|width=1179,height=574!
*As the job state in DB :*
{code:java}
mysql> select * from gobblin_job_queue where
job_name='DM-JOB-fpti-druid-dp-venmo' order by created_date desc limit 10;
+------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
| queue_id | job_name | deployment_id | failure_exception | configs | status |
job_id | created_date | updated_date |
+------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
| DM-JOB-fpti-druid-dp-venmo_1630444318758 | DM-JOB-fpti-druid-dp-venmo | 2 |
NULL |
\{"dataset":{"batch_id":"20210831211155","name":"default._druid-test_dataproc-jobs_venmo","snapshot_id":"20210831211155"},"gobblin":\{"client":{"id":"AIRFLOW_PAZ_DMP_DO"},"deployment":\{"name":"DMP228"}},"namespace":"Chunnel"}
| LAUNCHED | job_DM-JOB-fpti-druid-dp-venmo_1630444325903 | 2021-08-31
21:12:00 | 2021-08-31 21:12:38 |
{code}
*Acceptance Criteria:*
# Gobblin Jobs should be resumed, even if GobblinAppMaster gets restarted when
the Jobs are not finalized.
# The system should automatically resume jobs that were in the
RUNNING/LAUNCHED/SUBMITTED state after the restart.
# The solution should address lingering locks acquired in the previous run.
# It should not pick up the jobs/clean locks that are being picked up by other
deployments, as part of work stealing.
was:
*Context:*
Following a restart, Gobblin service is currently unable to process previous
jobs in the RUNNING/LAUNCHED/SUBMITTED state, resulting in a stuck state for
these jobs.
*Example scenario mentioned here*
A job is in the LAUNCHED state, and while calculating CDC, the Application
master got re-attempted, actually due to name node issue (can be any env
issues).
!2ac4a7d8-f168-4877-a583-03d62f1384ac.png|width=1179,height=574!
*As the job state in DB :*
{code:java}
mysql> select * from gobblin_job_queue where
job_name='DM-JOB-fpti-druid-dp-venmo' order by created_date desc limit 10;
+------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
| queue_id | job_name | deployment_id | failure_exception | configs | status |
job_id | created_date | updated_date |
+------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
| DM-JOB-fpti-druid-dp-venmo_1630444318758 | DM-JOB-fpti-druid-dp-venmo | 2 |
NULL |
\{"dataset":{"batch_id":"20210831211155","name":"default._druid-test_dataproc-jobs_venmo","snapshot_id":"20210831211155"},"gobblin":\{"client":{"id":"AIRFLOW_PAZ_DMP_DO"},"deployment":\{"name":"DMP228"}},"namespace":"Chunnel"}
| LAUNCHED | job_DM-JOB-fpti-druid-dp-venmo_1630444325903 | 2021-08-31
21:12:00 | 2021-08-31 21:12:38 |
{code}
*Acceptance Criteria:*
# Gobblin Jobs should be resumed, even if GobblinAppMaster gets restarted when
the Jobs are not finalized.
# The system should automatically resume jobs that were in the
RUNNING/LAUNCHED/SUBMITTED state after the restart.
# The solution should address lingering locks acquired in the previous run.
# Care should be taken to avoid picking up jobs or cleaning locks that are
currently being handled by other deployments as part of work stealing.
#
> Following the restart, jobs that were previously in the "RUNNING,"
> "LAUNCHED," or "SUBMITTED" state failed to resume.
> ----------------------------------------------------------------------------------------------------------------------
>
> Key: GOBBLIN-1963
> URL: https://issues.apache.org/jira/browse/GOBBLIN-1963
> Project: Apache Gobblin
> Issue Type: Bug
> Components: misc
> Affects Versions: 0.15.0
> Reporter: Apekshit Kumar
> Priority: Minor
> Attachments: 2ac4a7d8-f168-4877-a583-03d62f1384ac.png
>
>
> *Context:*
> Following a restart, Gobblin service is currently unable to process previous
> jobs in the RUNNING/LAUNCHED/SUBMITTED state, resulting in a stuck state for
> these jobs.
> *Example scenario mentioned here*
> A job is in the LAUNCHED state, and while calculating CDC, the Application
> master got re-attempted, actually due to name node issue (can be any env
> issues).
>
> !2ac4a7d8-f168-4877-a583-03d62f1384ac.png|width=1179,height=574!
>
> *As the job state in DB :*
> {code:java}
> mysql> select * from gobblin_job_queue where
> job_name='DM-JOB-fpti-druid-dp-venmo' order by created_date desc limit 10;
> +------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
> | queue_id | job_name | deployment_id | failure_exception | configs | status
> | job_id | created_date | updated_date |
> +------------------------------------------+----------------------------+---------------+-------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+----------------------------------------------+---------------------+---------------------+
> | DM-JOB-fpti-druid-dp-venmo_1630444318758 | DM-JOB-fpti-druid-dp-venmo | 2 |
> NULL |
> \{"dataset":{"batch_id":"20210831211155","name":"default._druid-test_dataproc-jobs_venmo","snapshot_id":"20210831211155"},"gobblin":\{"client":{"id":"AIRFLOW_PAZ_DMP_DO"},"deployment":\{"name":"DMP228"}},"namespace":"Chunnel"}
> | LAUNCHED | job_DM-JOB-fpti-druid-dp-venmo_1630444325903 | 2021-08-31
> 21:12:00 | 2021-08-31 21:12:38 |
> {code}
>
> *Acceptance Criteria:*
> # Gobblin Jobs should be resumed, even if GobblinAppMaster gets restarted
> when the Jobs are not finalized.
> # The system should automatically resume jobs that were in the
> RUNNING/LAUNCHED/SUBMITTED state after the restart.
> # The solution should address lingering locks acquired in the previous run.
> # It should not pick up the jobs/clean locks that are being picked up by
> other deployments, as part of work stealing.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
