6,849
社区成员
发帖
与我相关
我的任务
分享windows2003上传附件速度超慢的原因？
用JAVA开发了一套业务系统，放到服务器上，并用Weblogic将其发布，之前的操作系统是没有打SP1或SP2补丁的windows2003，从客户机登录业务系统后上传附件时无论是多大的附件都能够以很快的速度上传成功并将数据入库，前天系统崩溃了，重装时安装的是打了SP2补丁的win2003，重新部署好业务系统后，测试时用的是一个大小只有几M的附件，上传速度很快，当时以为没有问题了，所以就正式启用了，但今天业务员在上传附件时，大于20M的附件上传速度都很慢，有时还传不成功，拿到服务器上去上传时，速度又很快，说明业务系统在部署时没有出错，请问一下这个是windows2003的原因造成的吗？是系统有什么限制吗？我在网上搜索了一下都介绍的是IIS下的解决方案
...全文
请发表友善的回复…
发表回复
flyfranker 2008-12-04
- 打赏
- 举报
Struts FileUpload 异常处理之Processing of multipart/form-data request failed.
问题：
在使用FileUpload的过程中，有一个经常抛出异常如下：
ERROR [http-8081-Processor21] (CommonsMultipartRequestHandler.java:201) -2008-04-10 11:20:27,671 Failed to parse multipart request
org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. temp\upload__3d7cf8b_11936276cf8__7ffd_00000011.tmp (系统找不到指定的路径。)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:268)
at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:193)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:443)
at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:804)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
问题分析：
在我使用Struts FileUpload时有以下几个关键部分：
定义Form的Enctype属性multipart/form-data，添加<input type=file>的域；
在FormBean中定义与file域名称相同、类型为FormFile的属性；
在strut-config.xml定义或修改controller标记，分别设置maxFileSize=10M、bufferSize=4096、tempDir=temp、inputForward=true等属性；
获得FormFile类型的属性，将字节流写入指定的文件中。
而在不超出maxFileSize的范围中有一些较大文件都不能上传成功，并抛出上述异常，在指定的tempDir目录中也不能找到相应的tmp文件。在已知的单独使用commons-fileupload时经常使用的handler是ServletFileUpload或DiskFileUpload，而在查到的资料中的解释是使用DiskFileUpload就可以解决上面的问题，那么StrutsFileUpload是怎么使用这些类来处理上传的呢？查看struts-config_1_2.dtd有一个属性是multipartClass是用来设置处理这种请求的类，默认值是CommonsMultipartRequestHandler，那么应该有其它不同的处理类，于是在"org.apache.struts.upload中找到类DiskMultipartRequestHandler。这个类的处理方式是直接在临时文件目录写临时文件。那么定义multipartClass=org.apache.struts.upload.DiskMultipartRequestHandler，则异常不再出现。
但是javadoc中明明白白的写的是在commons-fileupload以后的版本中DiskMultipartRequestHandler类将由CommonsMultipartRequestHandler替代，使用CommonsMultipartRequestHandler才是明智的选择。那么分析一下，发现后者可用的原因就应该在于后者是使用硬盘空间作为交换空间，则前者就应当是使用内存做为交换空间的，那么使用内存空间应该是有边界限制的，这个属性就是memFileSize，其默认值是256K，在上传抛出异常时使用的文件就是大于这个数字的文件，发现它对应的其实就是DiskFileItemFactory的sizeThreshold属性。而对memFileSize的解释就是上传时可以在内存中保留的文件的最大值，超出这个数字则保存在其它的介质中如硬盘。也就是说要正常使用CommonsMultipartRequestHandler类处理上传请求，可以将memFileSize定义到与maxFileSize一样大，但显而易见的是一旦有更大的上传文件需求时，就会重新遇到问题，如此大的内存开销是显然是不合理的。
按道理来讲，CommonsMultipartRequestHandler做为multipartClass默认值和下一版本的保留类，应该是可以正确的使用配置文件中定义的memFileSize属性的，那么既然在异常中有“系统找不到指定的路径”字样，那就从文件系统的路径来试着解决问题。tempDir指定的目录是temp，异常的提示应该就是找不到这个目录，从本机应用中来看这个temp就是tomcat根目录下的temp，但就是这个目录在我本机上是可以找到的，在服务器上却总是提示异常。查看struts-config_1_2.dtd，对于这个参数的解释是“指定文件上传时的临时工作目录.如果没有设置,将才用Servlet容器为web应用分配的临时工作目录”。那么在我的应用中如果不指定tempDir，这个目录就是%TOMCAT_HOME%\temp；如果指定的话，就要指定绝对路径，如“C:\\temp”。
解决方法：
1、指定multipartClass为org.apache.struts.upload.DiskMultipartRequestHandler，不推荐使用这种方式；
2、指定memFileSize与maxFileSize相同的值，用于上传文件较小的情况，这种方式其实也是一种错误的方式，不推荐；
3、指定tempDir为绝对目录；
4、如果应用服务器可以为应用分配临时目录的话，可以不指定tempDir；
5、即便tempDir指定的是相对目录，如tempDir="temp"，也并不是错误的，它应该是存在于当然应用的一个相对目录。
补充：
tempDir指定的目录中可能会随着时间推移出现很多后缀为"tmp"的垃圾文件，commons-fileupload提供了一个不错的解决方法，就是把下面的代码加入到web.xml中即可。
<listener>
<listener-class>
org.apache.commons.fileupload.servlet.FileCleanerCleanup
</listener-class>
</listener>
需要注意的是FileCleanerCleanup是commons-fileupload1.2以后的版本才有的类。
Google了一下，希望这篇文章对你有用。
问题：
在使用FileUpload的过程中，有一个经常抛出异常如下：
ERROR [http-8081-Processor21] (CommonsMultipartRequestHandler.java:201) -2008-04-10 11:20:27,671 Failed to parse multipart request
org.apache.commons.fileupload.FileUploadException: Processing of multipart/form-data request failed. temp\upload__3d7cf8b_11936276cf8__7ffd_00000011.tmp (系统找不到指定的路径。)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:384)
at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:268)
at org.apache.struts.upload.CommonsMultipartRequestHandler.handleRequest(CommonsMultipartRequestHandler.java:193)
at org.apache.struts.util.RequestUtils.populate(RequestUtils.java:443)
at org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:804)
at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
问题分析：
在我使用Struts FileUpload时有以下几个关键部分：
定义Form的Enctype属性multipart/form-data，添加<input type=file>的域；
在FormBean中定义与file域名称相同、类型为FormFile的属性；
在strut-config.xml定义或修改controller标记，分别设置maxFileSize=10M、bufferSize=4096、tempDir=temp、inputForward=true等属性；
获得FormFile类型的属性，将字节流写入指定的文件中。
而在不超出maxFileSize的范围中有一些较大文件都不能上传成功，并抛出上述异常，在指定的tempDir目录中也不能找到相应的tmp文件。在已知的单独使用commons-fileupload时经常使用的handler是ServletFileUpload或DiskFileUpload，而在查到的资料中的解释是使用DiskFileUpload就可以解决上面的问题，那么StrutsFileUpload是怎么使用这些类来处理上传的呢？查看struts-config_1_2.dtd有一个属性是multipartClass是用来设置处理这种请求的类，默认值是CommonsMultipartRequestHandler，那么应该有其它不同的处理类，于是在"org.apache.struts.upload中找到类DiskMultipartRequestHandler。这个类的处理方式是直接在临时文件目录写临时文件。那么定义multipartClass=org.apache.struts.upload.DiskMultipartRequestHandler，则异常不再出现。
但是javadoc中明明白白的写的是在commons-fileupload以后的版本中DiskMultipartRequestHandler类将由CommonsMultipartRequestHandler替代，使用CommonsMultipartRequestHandler才是明智的选择。那么分析一下，发现后者可用的原因就应该在于后者是使用硬盘空间作为交换空间，则前者就应当是使用内存做为交换空间的，那么使用内存空间应该是有边界限制的，这个属性就是memFileSize，其默认值是256K，在上传抛出异常时使用的文件就是大于这个数字的文件，发现它对应的其实就是DiskFileItemFactory的sizeThreshold属性。而对memFileSize的解释就是上传时可以在内存中保留的文件的最大值，超出这个数字则保存在其它的介质中如硬盘。也就是说要正常使用CommonsMultipartRequestHandler类处理上传请求，可以将memFileSize定义到与maxFileSize一样大，但显而易见的是一旦有更大的上传文件需求时，就会重新遇到问题，如此大的内存开销是显然是不合理的。
按道理来讲，CommonsMultipartRequestHandler做为multipartClass默认值和下一版本的保留类，应该是可以正确的使用配置文件中定义的memFileSize属性的，那么既然在异常中有“系统找不到指定的路径”字样，那就从文件系统的路径来试着解决问题。tempDir指定的目录是temp，异常的提示应该就是找不到这个目录，从本机应用中来看这个temp就是tomcat根目录下的temp，但就是这个目录在我本机上是可以找到的，在服务器上却总是提示异常。查看struts-config_1_2.dtd，对于这个参数的解释是“指定文件上传时的临时工作目录.如果没有设置,将才用Servlet容器为web应用分配的临时工作目录”。那么在我的应用中如果不指定tempDir，这个目录就是%TOMCAT_HOME%\temp；如果指定的话，就要指定绝对路径，如“C:\\temp”。
解决方法：
1、指定multipartClass为org.apache.struts.upload.DiskMultipartRequestHandler，不推荐使用这种方式；
2、指定memFileSize与maxFileSize相同的值，用于上传文件较小的情况，这种方式其实也是一种错误的方式，不推荐；
3、指定tempDir为绝对目录；
4、如果应用服务器可以为应用分配临时目录的话，可以不指定tempDir；
5、即便tempDir指定的是相对目录，如tempDir="temp"，也并不是错误的，它应该是存在于当然应用的一个相对目录。
补充：
tempDir指定的目录中可能会随着时间推移出现很多后缀为"tmp"的垃圾文件，commons-fileupload提供了一个不错的解决方法，就是把下面的代码加入到web.xml中即可。
<listener>
<listener-class>
org.apache.commons.fileupload.servlet.FileCleanerCleanup
</listener-class>
</listener>
需要注意的是FileCleanerCleanup是commons-fileupload1.2以后的版本才有的类。
Google了一下，希望这篇文章对你有用。
pass528 2008-12-04
- 打赏
- 举报
附件是压缩文件，因为是专有的后缀名，只有一个软件可以打开，打开后是很多表单，在上传时是要将表单中的数据写入到数据库每张表单对应的表中相应的字段去
flyfranker 2008-12-04
- 打赏
- 举报
对Weblogic不是很熟悉，你的上传附件是以文件形式直接存在服务器固定目录下，还是转换成二进制代码写进数据库的？
2003 sp2增加了很多重视安全性的限制，从安全角度去分析一下看看是不是能找到问题所在，比如说系统策略。
2003 sp2增加了很多重视安全性的限制，从安全角度去分析一下看看是不是能找到问题所在，比如说系统策略。
pass528 2008-12-04
- 打赏
- 举报
谢谢楼上的，但系统不是用.NET开发的啊，发布时也没有用到IIS啊，用到的是Weblogic发布
flyfranker 2008-12-04
- 打赏
- 举报
是的，IIS对上传文件大小是有限制的。
c:\windows\system32\inetsrv\metabase.xml 编辑此文件
ASPMaxRequestEntityAllowed 默认 204800-200K 修改为你指定的值
超过20M按照默认值是一定会出错的。
c:\windows\system32\inetsrv\metabase.xml 编辑此文件
ASPMaxRequestEntityAllowed 默认 204800-200K 修改为你指定的值
超过20M按照默认值是一定会出错的。
