commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: commons fileupload
Date Mon, 19 Jun 2006 19:36:35 GMT
On 6/19/06, Robert J. Carr <rjcarr@apl.washington.edu> wrote:
>
> Well, I set my 'setSizeThreshold()' to a fairly large number (2^24 or
> 16,777,216 or 16MB, far larger than the size of my file), but it is
> still doubling in size when uploaded.
>
> Again, strangely, I'm getting two files written, one automatically
> (which I thought would be gone now?) and one manually.
>
> The one written automatically (upload_0000002.xml) is correct (about
> 1MB); a copy of the file I uploaded.


Are you sure that's the name of the file being written? It doesn't match the
pattern for temp files created by FileUpload, so I'm not sure where that
would be coming from.

  Another file, which was created
> with this line:
>
> item.write(File.createTempFile("portaltest-", null));
>
> Comes back as twice the size, about 2MB, as portaltest-63344.tmp.
>
> I can/will hook up a tcp monitor, but the problem with that is, I'm
> sending up a lot of data, at least 1MB of XML.  Whenever I do small
> files, say ~100KB, it works fine.  So, here are my questions:
>
> 1) If I'm setting the 'setSizeThreshold()' large enough, why is it
> *still* writing out a temp file to disk?  Is this normal?


Nope. Are you sure you're setting the threshold on the factory before
calling parseRequest?

2) The documentation for 'getSizeThreshold()' says:  "Returns the size
> threshold beyond which files are written directly to disk. The default
> value is 1024 bytes".  But when I do a 'getSizeThreshold()' I get 10240.
>   Is the documentation simply stale?


That's a Javadoc error that I've now fixed. Thanks for pointing it out.

3) What happens between when the uploaded file is temporarily written to
> disk, and when the 'parseRequest()' is called?  Between these two events
> is when the size problems seem to manifest.


It's the parseRequest call that writes temp files to disk when necessary.
Pretty much nothing interesting happens outside of the parseRequest call.

--
Martin Cooper


Thanks-
> Robert
>
> Martin Cooper wrote:
> > On 6/18/06, Robert J. Carr <rjcarr@apl.washington.edu> wrote:
> >>
> >> Mike/Martin-
> >>
> >> I will hook up a monitor (I'm familiar with tcpmon) but as I
> >> explained, it
> >> seems to be beyond that point, as the file is written to disk correctly
> >> when done automatically, but then written incorrectly when done
> manually
> >> (or when referred to).
> >
> >
> > What's strange, though, is that nobody else has reported this kind of
> > problem, and the difference between the servlet and portlet code is
> > miniscule. The size of a file item is determined from the content itself
> by
> > the same code for both cases.
> >
> > I've read about a file-writing size threshold, and perhaps this is
> >> configurable?
> >
> >
> > Yes, it is. You can call the setSizeThreshold method on the file item
> > factory. See the user guide for an example.
> >
> > --
> > Martin Cooper
> >
> >
> >  As I also explained, the problem only seems to happen with
> >> large files, when they are written to disk and pass this
> threshold.  Not
> >> an ideal fix, but if I just move this threshold up considerably higher,
> >> I'm guessing it would work, and would at least allow me to see
> something
> >> different.
> >>
> >> I'll try that, and attach the moitor, and report my results.  Thanks
> for
> >> the time.
> >>
> >> Robert
> >>
> >> On Sat, 17 Jun 2006, Mike Sparr - www.goomzee.com wrote:
> >>
> >> > Martin,
> >> >
> >> > http://ethereal.com/  (very easy to use and when you run it, you can
> >> choose
> >> > which network adapter to capture traffic.  After you capture, then
> you
> >> can
> >> > run the viewer to analyze).
> >> >
> >> > In addition, I believe AXIS includes a network monitoring tool built
> >> into
> >> > the library so you may want to use that.  Perhaps you could tweak it
> to
> >> > Monitor other traffic, but again SOAP is http...
> >> >
> >> > org.apache.axis.monitor.SOAPMonitorService
> >> >
> >> > Hope that helps,
> >> >
> >> >
> >> > Mike
> >> >
> >> >
> >> >
> >> >
> >> > On 6/17/06 4:14 PM, "Martin Cooper" <martinc@apache.org> wrote:
> >> >
> >> > > On 6/15/06, Robert J. Carr <rjcarr@apl.washington.edu> wrote:
> >> > >>
> >> > >> I am attempting to use the fileupload package and having strange
> >> > >> results.  I have a file type form element that I am uploading
an
> xml
> >> > >> file through to.  The xml file I'm uploading is about 1.1MB
> >> .  However,
> >> > >> when I print some of the metadata about the uploaded FileItem,
> >> here's
> >> > >> what I get:
> >> > >
> >> > >
> >> > > Do you have any way of capturing what's on the wire, so that we
> could
> >> look
> >> > > at the contents of the incoming request? Maybe Windows Network
> >> Monitor
> >> or
> >> > > Ethereal or something? Without that, it will be hard to figure out
> >> what's
> >> > > going on.
> >> > >
> >> > > --
> >> > > Martin Cooper
> >> > >
> >> > >
> >> > > content-type: text/xml
> >> > >> size: 2363688 (via getSize())
> >> > >> length: 2363688 (via get().length)
> >> > >>
> >> > >> When I look in my tomcat temp directory, I see a file:
> >> > >>
> >> > >> upload_000000014.xml
> >> > >>
> >> > >> Which is the correct file, it is 1.1MB and passes diff.
> >> > >>
> >> > >> However, when I attempt to write the file to disk:
> >> > >>
> >> > >> item.write(File.createTempFile("portaltest-", null));
> >> > >>
> >> > >> I get a file written:
> >> > >>
> >> > >> portaltest-64578.tmp
> >> > >>
> >> > >> Which is incorrect, and a size of 2.3 MB (which matches the size
> >> above).
> >> > >>
> >> > >> I'm using the latest 1.1.1 release (but same thing happens with
> >> 1.1).
> >> > >> To get my fileitems, I make this sequence of calls:
> >> > >>
> >> > >> FileItemFactory factory = new DiskFileItemFactory();
> >> > >> PortletFileUpload upload = new PortletFileUpload(factory);
> >> > >> List<FileItem> items = (List<FileItem>)
> >> upload.parseRequest(request);
> >> > >>
> >> > >> To add another twist, this seems to work fine for smaller files
> >> (less
> >> > >> than about 50KB in size).
> >> > >>
> >> > >> I'm also getting an exception thrown later, and not entirely sure
> >> where
> >> > >> it is coming from.  It may be a red herring, but I'll include
it
> for
> >> > >> completeness:
> >> > >>
> >> > >> java.io.FileNotFoundException:
> >> > >>
> >> > >>
> >> >
> >>
> /opt/java/LiferayPro3.6.1/temp/upload__41c20f98_10bd8eb6a9d__7ffe_00000002.tm>>
> >>
> >> > p
> >> > >> (No such file or directory)
> >> > >>
> >> > >> So I have no idea what is going on.  My form is pretty basic ...
> >> here
> >> it
> >> > >> is as well:
> >> > >>
> >> > >> <form name="<portlet:namespace />fm" action="<portlet:actionURL
> />"
> >> > >> method="post" enctype="multipart/form-data">
> >> > >>    <input type="file" name="<portlet:namespace />rdssxml"
/>
> >> > >> </form>
> >> > >>
> >> > >> Any help would be appreciated.  Are there other upload packages
> >> similar
> >> > >> to filupload that I could try?  I've always found the jakarta
> tools
> >> to
> >> > >> be the most consistently well done, but I would like to test just
> >> for
> >> > >> sanity.
> >> > >>
> >> > >> Thanks-
> >> > >> Robert
> >> > >>
> >> > >>
> >> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail:
> commons-user-unsubscribe@jakarta.apache.org
> >> > >> For additional commands, e-mail:
> >> commons-user-help@jakarta.apache.org
> >> > >>
> >> > >>
> >> >
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message