# Reported upload issues with website **URL:** \ **Category:** NGINX\ **Created:** [April 10, 2010, 9:38am UTC](https://www.ruby-forum.com/t/reported-upload-issues-with-website/186641 "2010-04-10T09:38:15Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![Blake\_Scrivner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@Blake\_Scrivner](https://www.ruby-forum.com/u/Blake_Scrivner)\ **Post date:** [April 10, 2010, 9:38am UTC](https://www.ruby-forum.com/t/reported-upload-issues-with-website/186641/1 "2010-04-10T09:38:15Z")
Hello All, We are running our site on a RHEL server. Nginx is setup to proxy traffic to Tomcat. We are hearing reports from some users of issues uploading files. These issues are sporadically happening and it sounds like users with flakey connections are the ones affected. Based on what’s reported, I think there is an issue with a users connection timing out during the upload process. This is causing uploads to fail instead of keeping the session open until the timeout clears. The app (Grails) and Tomcat have a pretty long timeout set (30 min) so it doesn’t appear to be something there. I’m wondering if there are backend timeout issues with the proxy. Maybe a problem where Nginx closes the connection to the user or Tomcat once the user has timed out for a period of time. We’re running Nginx 0.7.64 and I’ve added both configuration files to [pastie.org](http://pastie.org). nginx.conf = [http://www.pastie.org/908712](http://www.pastie.org/908712) virtual.conf = [http://www.pastie.org/908714](http://www.pastie.org/908714) I’ve looked into the following directives and implementing the “suggest” values on staging tonight. proxy\_connect\_timeout… Default: proxy\_connect\_timeout 60; suggest: proxy\_connect\_timeout 240; proxy\_ignore\_client\_abort… default: proxy\_ignore\_client\_abort off suggest: proxy\_ignore\_client\_abort on proxy\_max\_temp\_file\_size default: proxy\_max\_temp\_file\_size 1G; suggested: proxy\_max\_temp\_file\_size 4G; proxy\_read\_timeout default: proxy\_read\_timeout 60 suggested: proxy\_read\_timeout 240 proxy\_send\_timeout default: proxy\_send\_timeout 60 suggested: proxy\_send\_timeout 240 client\_body\_timeout default: 60 suggested: client\_body\_timeout 240 [Show » [https://tracker.solutionset.com/browse/SAHMEDB-101](https://tracker.solutionset.com/browse/SAHMEDB-101) ] Blake Scrivner[https://tracker.solutionset.com/secure/ViewProfile.jspa?name=bscrivner](https://tracker.solutionset.com/secure/ViewProfile.jspa?name=bscrivner)added a comment - 07/Apr/10 04:05 PM I’m going to add those configurations above and below to stage and test to make sure everything is fine. If it is, then I’ll setup production to run with these new values. client\_body\_timeout default: 60 suggested: client\_body\_timeout 240 The problem with this issue is I haven’t been able to reproduce it, nor have clear cut steps to reproduce. No precise timestamps have been given so it makes using the logs pretty difficult. Here is an interesting clip from the error.log that might help identify the issue. Most of my research has shown this panic happens due to perl but this Nginx was compiled without the Perl module. panic: MUTEX\_LOCK (22) [op.c:352]. 2010/01/11 09:52:11 [error] 2250#0: \*10 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 12.228.184.2, server: [fileblaze.net](http://fileblaze.net), request: “POST /soundblaze/upload/fileUpload/ HTTP/1.1”, upstream: " [http://127.0.0.1:8080/soundblaze/upload/fileUpload/](http://127.0.0.1:8080/soundblaze/upload/fileUpload/)“, host: " [upload.fileblaze.net](http://upload.fileblaze.net)” Do you think those settings will help? Do I need all of these settings? Any other suggestions I should try out? Please let me know if there is any more data you would like me to gather to help troubleshoot this. Thanks in advance for all your help, Blake ---
**Author:** ![Blake\_Scrivner](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/3be4f8/32.png) [@Blake\_Scrivner](https://www.ruby-forum.com/u/Blake_Scrivner)\ **Post date:** [April 10, 2010, 8:55pm UTC](https://www.ruby-forum.com/t/reported-upload-issues-with-website/186641/2 "2010-04-10T20:55:32Z")
Hello! On Fri, Apr 09, 2010 at 12:02:04PM -0700, Blake Scrivner wrote: […] > The problem with this issue is I haven’t been able to reproduce it, nor have > clear cut steps to reproduce. No precise timestamps have been given so it > makes using the logs pretty difficult. Here is an interesting clip from the > error.log that might help identify the issue. Most of my research has shown > this panic happens due to perl but this Nginx was compiled without the Perl > module. > > panic: MUTEX\_LOCK (22) [op.c:352]. This is indeed message from perl. If you think you have no perl perl compiled in - you probably should re-investigate what you are actually running. For on-disk binary you may run nginx -V to see how nginx was configured. This may not match running binary though, so you may want to follow binary upgrade procedure as specified in docs (or just restart nginx) to make sure your running binary match on-disk one. > 2010/01/11 09:52:11 [error] 2250#0: \*10 upstream timed out (110: Connection > timed out) while reading response header from upstream, client: > 12.228.184.2, server: [fileblaze.net](http://fileblaze.net), request: “POST > /soundblaze/upload/fileUpload/ HTTP/1.1”, upstream: " > [http://127.0.0.1:8080/soundblaze/upload/fileUpload/](http://127.0.0.1:8080/soundblaze/upload/fileUpload/)“, host: " > [upload.fileblaze.net](http://upload.fileblaze.net)” This message indicate that upstream wasn’t able to process request in time. You should tune proxy\_read\_timeout if you want to take upstream some more time to process request. Maxim D.