[Cppcms-users] Uploads to slow storage devices

[Julian P. <ju...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hallo,

I recently experienced some problems when uploading (large) files (>=30
MB) with cherokee to a cppcms based backend application: After a part of
the upload has completed, a 500 Internal Server error is issued to the
browser and the connection (and upload) is terminated. These problems
only occur on an embedded board with a Cortex A8-ARM processor and a
very slow NAND memory (where the file shall be stored to). For file
corruption prevention, the file system (ext3) on this NAND is mounted in
sync mode so that no data is buffered in RAM but anything is written
directly to NAND. Even if async mode is used instead, the error occurs
after some more time (probably if the kernel's I/O buffer is full).
cherokee delivers the upload to the backend application via FastCGI.
My question is: Is there anything within the FastCGI/upload handling in
cppcms that may cause such a behaviour, if e.g. the backend application
needs to long to handle the request (because the file has to be stored
to NAND before the request is handled), or is it all the fault of the
webserver?
As a sidenote I may add that we successfully use the very same backend
application on several other systems with different architectures, but
faster storage devices and even on the very same board using SD cards
instead of onboard NAND.
As far as I know, the cherokee webserver passes uploaded files directly
to FastCGI applications (while other webservers like lighttpd or nginx
buffer the whole or at least part of the upload file before they deliver
it to the FastCGI application).

Thanks for your help,
Julian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPhY8dAAoJENidYKvYQHlQRuUP/20Ydttxaqk2rwCydAQKZZIz
DiqAzr0qL9FaJCHkUswOCYXhnp5upbB6qpBcjfYFE0Rtr81skGhLvP8b2EhyyU7X
bQ9wtvm/gYaigWhULtLs7XNDxQGVLWv3CEUD83h2gGqNFt1zGc/Er+R0ogjlFIFk
jbe94IXAzOpYRepIwKOifxdU+QOZCrcrvRZhRMiFnA+XxGBfQsZTHrIYCxCYAAIY
BBmcxrOMzyHhoVoZQNQDPPwqqbtpnUkxmWT2lHB5BBMvauokHSkRnvu73zxPonH3
WUj+6X4Jtc3CT9N2cbvzAnXqXUnFx5VWnIJ+aQuKUxqjStPE94DKdjxiJ4PHivQP
5f30ebdOxZa9SUHS+5liD+yIiojCYslyLpjciCCio4TFWxDoJdbPDns59Q/v5zQO
yyEh8+jKZq214HuiVaFW/jHOLPcOilsmS9ywsvz6FCXOhj4wHQH/Io7exoaa26i7
9Cr3SMsITyT3a0DnPfZZq9YsKy2K7Y0w6xp3MHP82gahOdaDMaiDAEXOaY/xT07v
8a17GQFRVsHFGLeILD16zE35YTH4tK5gJCZbL2lL9/8mbITcv8zNDzguP8vxXnuq
dQ/u33gU/Wqpc/pKgCkkTugMHCBRIhwshl+KWILoTuCuhBOyX9gHEOPWvAghNwkn
AoksBVwbHj5QWMwSEJsa
=yEBf
-----END PGP SIGNATURE-----