-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request 838 of 885 timed out, would you like to [A]bort or [S]kip or [R]etry and continue? #54
Comments
Thanks for the suggestion! This might be a little tricky to pull off because of the way I built the command line tool on top of the library, but I'll think through it some this week. |
Many thanks for considering it in a positive attitude!
I'd guess it may be easier to have a first cut with the 1000 chunks.
So a repeat, resume or restart would be on a 1000 whole chunk
regardless of where inside the chunk the actual failure occurred.
Still a bit of manual work to filter the overlap, but a huge improvement.
This will work best with --jsonlines and can be improved by good
reporting by the 'catch' code on the offset where the actual abort
occurred.
…On 7/9/18, Ian Dees ***@***.***> wrote:
Thanks for the suggestion! This might be a little tricky to pull off because
of the way I built the command line tool on top of the library, but I'll
think through it some this week.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#54 (comment)
|
👍 to automated retry, I commonly encounter things like below, which upon just trying again (I've hacked in a way to pass in the offset and total feature count) to pick up where we left off)
|
@ArieRudich Although this ticket is about being able to restart when timeouts occur, for your original timeout issue, if the layer has an ID field, then I've found forcing esri2geojson to query by ID range avoids timeouts, you can now do this with |
@andrewharvey I have this similar problem as described above, tried |
Let me start by giving BIG thanks for a most useful tool! THANKS!
The attached Traceback is of a timeout that occured after a LONG all night dump
(request 838 out of 885 requests using resultOffset method).
Might be a good idea to catch this and turn it into a user prompt, something like:
preferably with a default TimeOutRetry=3 ( or more general FailRetry ) and a flag argument to override it.
Another helpful aid in this and similar situations (Just had a "similar"situation with "socket.gaierror: [Errno 11002] getaddrinfo failed") can be to expose the --resultOffset so it can restart an aborted download at the offset last reported by -v or, even better, reported by the exception handler.
What do you think?
Thanks!
The text was updated successfully, but these errors were encountered: