commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Thorburn <nzi...@gmail.com>
Subject Re: Is DiskFileItemFactory Thread Safe?
Date Sun, 07 Feb 2010 05:35:44 GMT
Indeed. It's generally regarded as an anti-pattern.

evebill8: See below for a couple of links talking about it if your
co-workers grumble about it (and for anyone else who comes along
asking these questions, I guess).

http://c2.com/cgi/wiki$?PrematureOptimization
http://prematureoptimization.org/blog/archives/26
http://www.flounder.com/optimization.htm

Once you've read the above 3, read this one:

http://www.acm.org/ubiquity/views/v7i24_fallacy.html

Which provides a nice sanity check.

- Andrew Thorburn

On Fri, Feb 5, 2010 at 8:48 PM, Adrian Crum <adrian.crum@yahoo.com> wrote:
> This is good advice. I have seen innumerable emails that follow this same format: "I
want to change x code because it could be a performance problem." If you were having performance
problems, then any number of code profilers will tell you where the bottleneck is. Just looking
at a code fragment and assuming it will be a performance bottleneck is not wise.
>
> -Adrian
>
> --- On Thu, 2/4/10, Martin Cooper <martinc@apache.org> wrote:
>
>> From: Martin Cooper <martinc@apache.org>
>> Subject: Re: Is DiskFileItemFactory Thread Safe?
>> To: "Commons Users List" <user@commons.apache.org>
>> Date: Thursday, February 4, 2010, 9:21 PM
>> Unless you're using a truly antique
>> version of Java, the cost of
>> repeatedly instantiating DiskFileItemFactory is entirely
>> negligible.
>> The constructor does next to nothing, and the JVM already
>> optimizes
>> repeated class instantiations almost out of existence. If
>> you are
>> seeing performance issues with heavy load on your servlet,
>> this is
>> _not_ what you need to be looking at, believe me.
>>
>> To answer your question, though, the class is here:
>>
>> http://svn.apache.org/repos/asf/commons/proper/fileupload/trunk/src/java/org/apache/commons/fileupload/disk/DiskFileItemFactory.java
>>
>> from which you can see that there's not a lot going on in
>> there.
>>
>> --
>> Martin Cooper
>>
>>
>> On Thu, Feb 4, 2010 at 10:25 AM, evebill8 <evebill8@hotmail.com>
>> wrote:
>> >
>> > I have a servlet that will handle few hundread
>> thousand requests per day.  I
>> > am using the commons FileUpload to loop thru the
>> fields and file items.
>> > Here is the code
>> >
>> >
>> >    public void doPost(HttpServletRequest req,
>> HttpServletResponse res)
>> >            throws ServletException, IOException
>> {
>> >
>> >        try {
>> >            DiskFileItemFactory factory = new
>> DiskFileItemFactory();
>> >
>> >            ServletFileUpload upload = new
>> ServletFileUpload(factory);
>> >            List<FileItem> items =
>> upload.parseRequest(req);
>> >
>> >            for (FileItem item : items) {
>> >                ....
>> >            }
>> >        }
>> >        catch (Exception e) {
>> >            ...
>> >        }
>> >    }
>> >
>> > Since the servlet is being called so many times, can I
>> make the
>> > DiskFileItemFactory global static so it won't create
>> the factory object so
>> > many times?  In sum, is DiskFileItemFactory class
>> thread safe?
>> >
>> >
>> >    DiskFileItemFactory factory = new
>> DiskFileItemFactory();
>> >
>> >    public void doPost(HttpServletRequest req,
>> HttpServletResponse res)
>> >            throws ServletException, IOException
>> {
>> >
>> >        try {
>> >
>> >            ServletFileUpload upload = new
>> ServletFileUpload(factory);
>> >            List<FileItem> items =
>> upload.parseRequest(req);
>> >
>> >            for (FileItem item : items) {
>> >                ....
>> >            }
>> >        }
>> >        catch (Exception e) {
>> >            ...
>> >        }
>> >    }
>> >
>> > Thanks!
>> >
>> > --
>> > View this message in context: http://n4.nabble.com/Is-DiskFileItemFactory-Thread-Safe-tp1469216p1469216.html
>> > Sent from the Commons - User mailing list archive at
>> Nabble.com.
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: user-help@commons.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
>> For additional commands, e-mail: user-help@commons.apache.org
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message