[Cosmo-dev] bug 5078: read put request content into a tmp file
and compare the]
randy at osafoundation.org
Tue Oct 17 09:15:08 PDT 2006
Jared Rhine wrote:
> As I read this, this change (use of a temp file to check content-length on
> PUT) has a significant impact on Cosmo's operational profile, particularly
> disk I/O. It'd be nice to stick with an application which is CPU-bound. I
> dunno if there's a conclusion here, but damn, really, a temp file? Ick.
> Seems like a code smell to me. Is there no other reasonable way?
Yes by buffering the request into a file, you introduce the disk
subsystem into the
equation. There is another bug (6928) that may require this anyway.
is that the entire content blob is read into memory now. We do this
we need to consume the blob at least twice (once to parse and validate
another time to stream to the database. If we didn't buffer the data
(in memory, or on disk) then the inputstream from the servlet request
would be consumed
after parsing, and would be lost. The problem with buffering in memory
is what happens
when 50 PUTs come in with a 10MB resource. That's 500MB of memory. Is
going to happen? I guess we won't know until we see some real-world
usage. If we
start seeing OutOfMemory exceptions, then that is when we need to think
streaming to disk first.
Thinking about it, for regular DAV PUTs we could pass the servlet
directly to Hibernate and stream into DB. For a PUT of a calendar
could consume the servlet inputstream into an ical4j Calendar object,
stream the data to the DB by creating a data inputstream from the
The only problem is that after parsing the data into a Calendar object,
lose the byte-for-byte data blob if you then try to transform the
to a stream of data.
More information about the cosmo-dev