-
Notifications
You must be signed in to change notification settings - Fork 20
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
Stabilize REST API mode #43
Comments
Peekaboo fails with the following error if the connection to the API cannot be established. Afterwards Peekaboo is in an unresponsive state and does not retry or at least shut down.
|
michaelweiser
added a commit
to michaelweiser/PeekabooAV
that referenced
this issue
May 8, 2019
Downloading the full list of jobs gets less and less efficient as the number of current and past jobs increases. There is no way to filter down to specific job IDs. The limit and offset parameters of the list action of the API cannot be used to achieve a similar effect because the job list is not sorted by job/task ID and the parameters seem only meant to iterate over the whole list in blocks, not to extract specific jobs from it. The previous logic of determining the highest job ID at startup and requesting the next million entries from that offset on was therefore likely not working as expected and making us "blind" to status changes of jobs which end up below our offset in the job list. This change adjusts the CuckooAPI to make use of the list of running jobs we've had for some time now to work around this. Instead of getting a list of all jobs starting from the highest job id we saw at startup we just get each job's status individually. While this makes for more requests, it should over a longer runtime make for less network traffic and reliably get us the data we need about our jobs. Also, turn the shutdown_requested flag into an event so we can use its wait() method to also implement the poll interval and get immediate reaction to a shutdown request. Finally, we switch to endless retrying of failed job status requests paired with the individual request retry logic introduced earlier. On submission we still fail the submission process after timeouts or retries on the assumption that without the job being submitted to Cuckoo, our feedback to the client that analysis fail will cause it to resubmit and still avoid duplicates. Closes scVENUS#43.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current REST API mode works but needs additional error handling and testing for exceptional conditions and erros.
The text was updated successfully, but these errors were encountered: