DWR + FileUpload 多文件上传实例， 进度条 百分比 上传速度 文件大小...

WAR 包已更新， 修复中文乱码问题， 并采用了 Reverse Ajax技术

 

功能： 文件上传

特点： 动态显示进度， 百分比， 文件名， 文件长度， 上传速度... 剩下的自己看吧

主要技术： DWR， Apache commons FileUpload

原理： FileUpload实现上传功能， UploadListener 监听上传进度， DWR push (Reverse Ajax) 进度信息并更新页面， 实现无刷新多文件上传

运行环境： Tomcat 6， WAS 6 测试通过

 

WAR 包下载 见附件

 

 

顺便截个图：

 

cool~
好东西。

I just updated the WAR package with bug fixed. Please check...

BTW, if you're using Tomcat6, you may need to find uploaded files in it's temp folder, which is D:\tomcat6\temp for me.

还是没有我要的效果,多文件上传为何不能做到一框多选呢?
这样子一个个点好麻烦...

呵呵~请别介意我说的话.

不错的想法， 但这个演示版用的是HTML file控件， 所以就被它限制了。

其实有很多其他的方法上传多文件， 比如dojo最新版本中的基于flash的一个上传控件我就觉得很酷。 而且基于flash还可以做到Client端验证文件大小， 可以google下试试。

我问个问题，楼主你的进度条的实现，是采用不断发请求到服务端进行确认的方式么？

感谢关注！

YES, sir. 因为Demo 里用的是 Polling 方式获取服务端数据

没猜错的话, 潜台词是想问这种方法是不是很有性能问题。

需要补充的是：
0. 前提是用户要求看到精确的上传进度
1. 如果并发用户数多， 不建议采用， 原因不言而喻
2. DWR 的 Comet 方式可能好一点儿， 但如果条件 0，1 都成立， 估计这种方式也好不到哪去。 Piggyback 方式就更不用提了吧

发这个贴的一个目的是 sharing， 另一个目的是通过讨论能找到更好的方案， 欢迎继续探讨 ;-)

是这样的，HTTP长连接本质上相当于一个socket连接，如果采用HTTP长连接的方式最多就多占用一个socket连接，性能应该是可以接受的吧。

Icewubin 兄弟说的也不无道理。 我们在多用户并发这个极端条件下采用HTTP长连接， N个用户就会占用N个socket连接。 Application Server 会不会 connection starving？

用户在上传的时候本身就是一个HTTP长连接，如果说为了界面友好，多占一个HTTP长连接而已。
多消耗一倍的资源而已，只是连接数资源，带宽占用很小。

就是一个简单的取舍问题，对吧。

先不管这个方案真的在极端情况下有多烂，但是至少是可用的，如果访问量真的可喜的达到极端情况了，那就可以考虑其他方案应对了。

如果用你现在的方案，很快就会达到极端情况，也就是说，不同的方案，并发数负载不一样。