Did you see how is the original one ? My modification is very simple and wouldn't change what you want do to. 15KB is way too low, opening a file, writing in it and closing a file take too much time if your file is 30KB you are doomed.
If you put a threshold of 150KB then allocating that much memory for a text field of 0 character is still non-sense to me. Storage in DB is influent, if we were stocking in a file then we would have the cost to write in a file at some point, in our case we don't. Your example was about 30MB, HTTP is not made for uploads like this, for large uploads, FTP is recommended for any web server. I agree there may have a problem but the solution is not as simple as you say. I got people asking for my fix working on other projects that Nukes. I read people complaining about that problem on forums as well. We are not alone coping with that problem. In a perfect world it works and it's just a little bit faster but i don't know any project working in a perfect world. A solution might be to get rid of commons-upload and do the parsing by ourself. It is not a priority right now. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3847005#3847005 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3847005 ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
