[
https://issues.apache.org/jira/browse/GOBBLIN-1101?focusedWorklogId=413824&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-413824
]
ASF GitHub Bot logged work on GOBBLIN-1101:
-------------------------------------------
Author: ASF GitHub Bot
Created on: 01/Apr/20 06:58
Start Date: 01/Apr/20 06:58
Worklog Time Spent: 10m
Work Description: arekusuri commented on issue #2942:
GOBBLIN-1101(DSS-25241): Enhance bulk api retry for ExceedQuota
URL:
https://github.com/apache/incubator-gobblin/pull/2942#issuecomment-607071075
> This affects resource utilization and latency, so I think users may want
to control that based on their workload and priorities. For example, they may
want the ETL job to fail immediately and not retry or to have a longer polling
interval to reduce contention with higher priority jobs.
@htran1 thanks for your above comment.
Add sleep in the retry logic is to avoid resource consuming peak. The sleep
duration should be a random number. Nobody knows what is the right number to
set up. (to do a lot of experiments may help find out a optimal number)
It is not depending anything like table size.
Flow job developer would not be able to figure out what number to set up.
Leave users the key can only confuse them more.
> they may want the ETL job to fail immediately
Very good question. We have key "salesforce.fetchRetryLimit", if set to 0,
there won't be retry. Default retry limit is 5.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 413824)
Time Spent: 2h 40m (was: 2.5h)
> Enhance bulk api retry for ExceedQuota
> --------------------------------------
>
> Key: GOBBLIN-1101
> URL: https://issues.apache.org/jira/browse/GOBBLIN-1101
> Project: Apache Gobblin
> Issue Type: Bug
> Reporter: Alex Li
> Priority: Major
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> 1. ExceedQuota exception
> Below is SFDC doc about ExceedQuota
> {code:java}
> One of the limits customers frequently reach is the concurrent request limit.
> Once a synchronous Apex request runs longer than 5 seconds, it begins
> counting against this limit. Each organization is allowed 10 concurrent
> long-running requests. If the limit is reached, any new synchronous Apex
> request results in a runtime exception. This behavior occurs until the
> organization’s requests are below the limit.
> {code}
> If the ExceedQuota exception happens, we should let the thread sleep 5
> minutes and try again. There should not be a retryLimit for this exception.
> 2. Except stack in log file
> For example we set up retryLimit to 10, we retried 10 times, and failed; we
> need to print out exception stack in log file, there are 10 of them in the
> exception stack.
> SSL Exception(root cause) ----retry and get ----> ExceedQuota ----retry and
> get ----> ExceedQuota ----....a lot........ ---->
> We'd better skip all the retry exception, only keep the root cause exception.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
