Re: WOFileUpload, Apache and large file

Ian Baxter <[email protected]>
Newsgroups gmane.comp.web.webobjects.devel
Message-ID <[email protected]>
Hi,

Do you have concurrent request handling turned on for your app? If  
this is off, which I believe it is by default, your instances will  
only handle one request at a time.

Before turning concurrent request handling on, you should make sure  
your code is thread safe -- paying attention to resources that are  
shared across sessions.

Here are some, perhaps, useful links:
http://www.wodeveloper.com/omniLists/webobjects-dev/2005/June/ 
msg00149.html
http://developer.apple.com/documentation/WebObjects/Reference/API/com/ 
webobjects/appserver/ 
WOApplication.html#isConcurrentRequestHandlingEnabled()

Hope that helps.

Ian

On Oct 2, 2006, at 3:50 PM, John Escott wrote:

> Hello,
>
> I have an application which accepts file uploads using  
> WOFileUpload. It's
> deployed on Linux (WO5.2) and uses the default adaptor and Apache  
> as the
> Web server. The WOFileUpload uses the outputStream binding so the file
> data goes to disk and this normally works fine.
>
> This morning a customer uploaded a large file which took a long  
> time to
> upload (59 mins). During this time, all other users with sessions  
> in the
> same app instance were "locked out" (received various http errors (500
> etc) to the effect that the app was unavailable). I deduce that  
> this is
> because the app only has 1 tcp connection to Apache which is  
> exclusively
> used by the file data.
>
> Has anyone encountered this problem before? Is there any way round it?
> I've created a few more instances so fewer users should now be  
> affected by
> it if it happens again (but most file uploads are much smaller and  
> quicker
> anyway). But I'd like to know if there's a better fix.
>
> best regards, John Escott.
> _______________________________________________
> WebObjects-dev mailing list
> [email protected]
> http://www.omnigroup.com/mailman/listinfo/webobjects-dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.