[Cosmo-dev] bug 5078: read put request content into a tmp file and compare the]

Randy Letness 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[1] 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.  
The problem
is that the entire content blob is read into memory now.  We do this 
because
we need to consume the blob at least twice (once to parse and validate 
icalendar) and
another time to stream to the database.  If we didn't buffer the data 
somewhere
(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 
this even
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 
about
streaming to disk first.

Thinking about it, for regular DAV PUTs we could pass the servlet 
inputstream
directly to Hibernate and stream into DB.  For a PUT of a calendar 
resource, we
could consume the servlet inputstream into an ical4j Calendar object, 
and then
stream the data to the DB by creating a data inputstream from the 
Calendar object.
The only problem is that after parsing the data into a Calendar object, 
you may
lose the byte-for-byte data blob if you then try to transform the 
Calendar object
to a stream of data.

-Randy


More information about the cosmo-dev mailing list