You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Call listFinishedTasks while there are any not completed tasks from taskIds
// Please note: API call 'listFinishedTasks' returns maximum 100 tasks
// So, to get all our tasks we need to delete tasks on server. Avoid running
// parallel programs that are performing recognition with the same Application ID
Given the limit of 100 results, sorted by date ascending (?!), and with no way of paginating, it's necessary to manually delete each completed task once it's been downloaded. This seems very flaky — if the program crashes before completion, leaving several tasks un-downloaded, those tasks will presumably just hang around taking up space on the list of returned tasks forever. Once the number of such zombie tasks reaches 100, calls to /listFinishedTasks will never return any relevant tasks, so the program will continue polling the endpoint forever until manually terminated.
Also, is there any real drawback to just polling /getTaskStatus for each ongoing task? It's not clear what the benefit of polling /listFinishedTasks is, given the increased complexity and flakiness. Presumably calls to /getTaskStatus are cheap, as they don't send or return much data or do any processing, just check a status.
The text was updated successfully, but these errors were encountered:
Per
JavaScript/ocrsdk.js
:ocrsdk.com/JavaScript/ocrsdk.js
Lines 125 to 127 in 3087b80
It looks like the only sample that actually implements this recommendation is
Java/Abbyy.Ocrsdk.client/srcProcessManyFiles.java
:ocrsdk.com/Java/Abbyy.Ocrsdk.client/src/ProcessManyFiles.java
Lines 245 to 250 in 3087b80
Given the limit of 100 results, sorted by date ascending (?!), and with no way of paginating, it's necessary to manually delete each completed task once it's been downloaded. This seems very flaky — if the program crashes before completion, leaving several tasks un-downloaded, those tasks will presumably just hang around taking up space on the list of returned tasks forever. Once the number of such zombie tasks reaches 100, calls to
/listFinishedTasks
will never return any relevant tasks, so the program will continue polling the endpoint forever until manually terminated.Also, is there any real drawback to just polling
/getTaskStatus
for each ongoing task? It's not clear what the benefit of polling/listFinishedTasks
is, given the increased complexity and flakiness. Presumably calls to/getTaskStatus
are cheap, as they don't send or return much data or do any processing, just check a status.The text was updated successfully, but these errors were encountered: