Failed download records .zip folder from project submission page

Support
1

Hi everybody,

I'm using ODK Central (v0.5) installed on DigitalOcean docker (plan Standard / 1 GB / 1 vCPU).
I can't create a valid .zip folder with my submissions records. This happens with the most complex questionnaires and with those that contain photos (one per questionnaire). For each questionnaire there are more than 50 records. Is this a problem with the server memory?

Will be very grateful for help. Thanks

2

This may be related related to another export error reported here.

What kind of failure message do you get in the browser when attempting to download? A user has described a timeout after 60 seconds here. Does it look like the same thing is happening?

3

Thank you!
w/ briefcase works fine!

4

That’s great! We do want it to work directly from Central as well and the behavior you’re describing is unexpected. Any more I do you can provide on what you’re seeing will be appreciated!

5

Is the failure you are getting an empty zip file?

I chatted with @issa about this and it seems likely that your original hypothesis about memory is correct. Specifically, reading media files out of the database to build the zip can fill available memory. Unfortunately, there's no way to detect that case and provide a more helpful error message so you just end up with an empty zip file.

This is documented in the obtaining a server docs:

If you don't expect many forms to be submitted at once and you don't expect many large media attachments, you can start with 1GB. Higher-load servers and servers which handle many image or video attachments may need 2GB or more. It is pretty easy to upgrade to a larger size later.

It might be helpful to pull this text out into a note and possibly to mention the empty zip file so users can more easily identify that this is the problem they experience.

Some options:

We haven't tried adding swap so if you do try it, please report back on performance. Note that we would not encourage anyone to rely on swap constantly. We recommend a swappiness property of 0 so that it is only used when absolutely necessary.

6

@LN I'm getting the same issue, hitting export zip opens a new tab, but then does nothing.

Details:

  • self-hosted ODK Central, K8s on Azure, v0.6 (this setup Installing ODK central in microsoft azure cloud - #2 by Florian_May)
  • installation has known problem with sending emails vs SSL certificates, working on it
  • Some forms download fine as zip: one zip comes with 17 submissions and attachments at 9MB, another one has 7 submissions and no attachments at 2kB
  • Some forms do not download: one form with 127 submissions with photos, another form with 75 submissions without photos
  • Our forms will grow over the now starting field season to ca 12k submissions with ca 200GB of attachments. We will access the submissions via OData to ingest incrementally into our data warehouse.
  • on export zip, no memory spike in backend
  • form has 75 submissions, no attachments
  • new tab "blank.html" opens, nothing happens for ca 60 seconds, no network requests I can see through Firefox console other than "blank.html", certainly not the URL ending in .zip
    Download started at 7:22am local time:
    image
    image2870×1660 271 KB

There's some more profiling I need to do on my end.
Using ruODK I can access the 75 records via the OData API within a second or so.
Using ruODK's submission export to zip, I'm also getting an error:

> ruODK::submission_export()
Error in curl::curl_fetch_disk(url, x$path, handle = handle) : 
  transfer closed with outstanding read data remaining

But running ruODK's test suite which is using the ODK Central sandbox, the zip export works fine. So my installation is what we call in expert programmer-dad-joke circles "nginxed".

All I can contribute here is that I'm not maxing out on RAM or any other server metric, and I can access the data fine via the OData API.

7

Given that there's no memory spike and you get the blank page after ~60secs, it sounds like it could be related to this issue patched by @issa. The 75-submission-no-media case seems really odd, though, especially since you can successfully access via OData API in a second.

:see_no_evil:

8

Just working on getting a second ODK Central up and running which is a pain in the k8s.
Seems like https://github.com/opendatakit/central/pull/95 might be the answer.

1 Like
9

especially since you can successfully access via OData API in a second.

OData is way lighter than the csv-zip export: no zipping, no attachments, etc etc. it also streams continually, whereas the zip stream has to work in ~25KB chunks because zip.

1 Like