Discussion:
Upload stop after 30 minutes: Processing of multipart/form-data request failed. Stream ended unexpectedly
Patrick Herber
2009-05-21 21:10:02 UTC
Permalink
Hello,

We have a struts based application running on a Tomcat 6 server sitting
behind an Apache HTTPD Server.
I'm experiencing problems uploading big files on it: after around 30
minutes (nearly exactly 30 minutes!) the upload stops.
I've tried to solve them with several combinations but until now I
didn't find any solution.

In the "standard" configuration we have Apache HTTPD with mod_ssl
connected through *mod_proxy_ajp* to the *AJP Connector* of Tomcat.

Apache httpd-ssl.conf:

<IfModule mod_proxy_ajp.c>
ProxyRequests Off
ProxyTimeout 3600
ProxyPass /error !
<Location / >
ProxyPass ajp://172.31.252.17:8009/
ProxyPassReverse ajp://172.31.252.17:8009/
</Location>
</IfModule>

Tomcat server.xml file:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

With this configuration I get a *FileUploadBase$IOFileUploadException*
("*Processing of multipart/form-data request failed. null*") with
following stacktrace:

----------------------------
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. null
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
at
ch.arpage.agora.util.MultiPartClassHandler.handleRequest(MultiPartClassHandler.java:220)
at
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:442)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:816)
at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)
at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
ch.arpage.agora.util.strip.StripFilter.doFilter(StripFilter.java:82)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
ch.arpage.agora.util.compression.CompressionFilter.doFilter(CompressionFilter.java:116)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:190)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:697)
at
org.apache.jk.common.ChannelSocket$SocketConnection.runIt(ChannelSocket.java:889)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException
at
org.apache.jk.common.JkInputStream.receive(JkInputStream.java:199)
at
org.apache.jk.common.JkInputStream.refillReadBuffer(JkInputStream.java:258)
at org.apache.jk.common.JkInputStream.doRead(JkInputStream.java:177)
at org.apache.coyote.Request.doRead(Request.java:428)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:304)
at
org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:405)
at
org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:327)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:193)
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:977)
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)
at java.io.InputStream.read(InputStream.java:89)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
... 30 more
----------------------------

On the Apache site (error_log) I don't have any message.

If - instead of mod_ajp_proxy - I use *mod_http_proxy* connected to the
*HTTP 1.1 connector*

<IfModule mod_proxy_http.c>
ProxyRequests Off
ProxyTimeout 3600
ProxyPass /error !
<Location / >
ProxyPass http://172.31.252.17:8080/
ProxyPassReverse http://172.31.252.17:8080/
</Location>
</IfModule>

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />

Than on the Tomcat site I also have a
FileUploadBase$IOFileUploadException but with a different message
"*Processing of multipart/form-data request failed. Stream ended
unexpectedly*":

----------------------------
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing of multipart/form-data request failed. Stream ended unexpectedly
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)

at
org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)

at
ch.arpage.agora.util.MultiPartClassHandler.handleRequest(MultiPartClassHandler.java:220)

at
org.apache.struts.util.RequestUtils.populate(RequestUtils.java:442)
at
org.apache.struts.action.RequestProcessor.processPopulate(RequestProcessor.java:816)

at
org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:203)

at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196)
at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at
ch.arpage.agora.util.strip.StripFilter.doFilter(StripFilter.java:82)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at
ch.arpage.agora.util.compression.CompressionFilter.doFilter(CompressionFilter.java:116)

at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)

at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)

at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by:
org.apache.commons.fileupload.MultipartStream$MalformedStreamException:
Stream ended unexpectedly
at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.makeAvailable(MultipartStream.java:983)

at
org.apache.commons.fileupload.MultipartStream$ItemInputStream.read(MultipartStream.java:887)

at java.io.InputStream.read(InputStream.java:89)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:94)
at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
at
org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)

... 27 more
----------------------------

and this time on the Apache error_log file following message appears:

[Wed May 20 11:34:45 2009] [error] proxy: pass request body failed to
172.31.252.17:8080 (172.31.252.17) from 172.31.252.1 ()

As I told you I tried several solution:

* using the last SVN version of *commons-fileupload* library (1.3
snapshot instead of 1.2.1)
* forcing in tomcat server.xml the parameter *disableUploadTimeout*=true
* In Apache setting the *Timeout* to 3600 seconds (1 hour)
* In the proxy configuration setting following properties:
*SetEnv force-proxy-request-1.0 1
SetEnv proxy-nokeepalive 1*
* Trying not to use HTTPS but connecting directly Apache on HTTP to
Tomcat


However nothing seems to help: after 30 minutes the upload breaks down.
To be honest I really don't know what to do.

Our application has an upload progress indicator, which is updated every
X seconds through AJAX calls: for this reason it's this not a problem of
session-timeout, which is kept alive through this calls.

Our Server is running Solaris 10, but I've also tried on a Linux (Suse)
with exactly the same result.

What could be the problem? Do you have any suggestion?
Please, tell me if you need some more information.

Thanks a lot for your help.

Best regards,

Patrick

Patrick Herber
Lugano, Switzerland
Caldarale, Charles R
2009-05-21 22:15:33 UTC
Permalink
Subject: Upload stop after 30 minutes: Processing of multipart/form-
data requestfailed. Stream ended unexpectedly
I'm experiencing problems uploading big files on it: after around 30
minutes (nearly exactly 30 minutes!) the upload stops.
What happens if you go directly into port 8080, bypassing httpd?

I realize it shouldn't have anything to do with the session timeout (and your AJAX requests should be resetting the timer), but that's the only thing I can think of in Tomcat that has a default value of 30 minutes. Just for grins, what happens if you change that to 60? Or 10?

Is there anything in between httpd and Tomcat (e.g., firewall) that might be dropping the connection?

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Patrick Herber
2009-05-22 12:13:35 UTC
Permalink
Thanks a lot for your reply!

I've tried your suggestions this are the results.
Post by Caldarale, Charles R
What happens if you go directly into port 8080, bypassing httpd?
I've tried but I get the same exception
Post by Caldarale, Charles R
Just for grins, what happens if you change that to 60? Or 10?
I've tried but nothing has changed...
Post by Caldarale, Charles R
Is there anything in between httpd and Tomcat (e.g., firewall) that
might be dropping the connection?
No (and now that I've tested directly on tomcat I presume that it's
either a Tomcat or a Commons FileUpload configuration problem)

Looking after the problem I also found a suggestion to explicity set
"disableUploadTimeout to false" (see
http://www.tek-tips.com/viewthread.cfm?qid=627123): I've also tried this
one but without success...

Any other suggestion?

Thanks a lot again for your help

Patrick
Post by Caldarale, Charles R
Subject: Upload stop after 30 minutes: Processing of multipart/form-
data requestfailed. Stream ended unexpectedly
I'm experiencing problems uploading big files on it: after around 30
minutes (nearly exactly 30 minutes!) the upload stops.
What happens if you go directly into port 8080, bypassing httpd?
I realize it shouldn't have anything to do with the session timeout (and your AJAX requests should be resetting the timer), but that's the only thing I can think of in Tomcat that has a default value of 30 minutes. Just for grins, what happens if you change that to 60? Or 10?
Is there anything in between httpd and Tomcat (e.g., firewall) that might be dropping the connection?
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
will trillich
2009-05-22 18:01:32 UTC
Permalink
Hmm. This sounds kinda like something we ran into lately -- maybe this
will help you:
- our server had TWO nic cards, one for internal 10.10.*.* one for
external 208.*.*.*
- we'd accidentally set up 'default gateway' on both

This meant the system was confused as to where to send replies. Looked
like a firewall issue, a router issue... but it was just a
mis-configuration in the network settings. Ports didn't matter,
firewall was okay, router couldn't get a dependable response...

E.G. if your IPs are 10.10.10.10/255.255.0.0 and
1.2.3.4/255.255.255.240 then your network knows which interface a
packed aimed at 10.10.1.1 should go out on, or where a packet aimed at
1.2.3.7 should go out on. But where would a packet aimed at
222.222.222.222 go? That's when you have a default gateway, which in
this case would probably be something like 1.2.3.1.

In case this helps.

On Fri, May 22, 2009 at 7:13 AM, Patrick Herber
Post by Patrick Herber
Thanks a lot for your reply!
I've tried your suggestions this are the results.
Post by Caldarale, Charles R
What happens if you go directly into port 8080, bypassing httpd?
I've tried but I get the same exception
Post by Caldarale, Charles R
Just for grins, what happens if you change that to 60? Or 10?
I've tried but nothing has changed...
Post by Caldarale, Charles R
Is there anything in between httpd and Tomcat (e.g., firewall) that might
be dropping the connection?
No (and now that I've tested directly on tomcat I presume that it's either a
Tomcat or a Commons FileUpload configuration problem)
Looking after the problem I also found a suggestion to explicity set
"disableUploadTimeout to false" (see
http://www.tek-tips.com/viewthread.cfm?qid=627123): I've also tried this one
but without success...
Any other suggestion?
Thanks a lot again for your help
Patrick
Post by Caldarale, Charles R
Subject: Upload stop after 30 minutes: Processing of multipart/form-
data requestfailed. Stream ended unexpectedly
I'm experiencing problems uploading big files on it: after around 30
minutes (nearly exactly 30 minutes!) the upload stops.
What happens if you go directly into port 8080, bypassing httpd?
I realize it shouldn't have anything to do with the session timeout (and
your AJAX requests should be resetting the timer), but that's the only thing
I can think of in Tomcat that has a default value of 30 minutes.  Just for
grins, what happens if you change that to 60?  Or 10?
Is there anything in between httpd and Tomcat (e.g., firewall) that might
be dropping the connection?
 - Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
--
will trillich
"Our only real economic security lies in our power to meet human
needs." -- S.Covey, the 8th Habit
Christopher Schultz
2009-05-22 19:22:59 UTC
Permalink
Will,
Post by will trillich
Hmm. This sounds kinda like something we ran into lately -- maybe this
- our server had TWO nic cards, one for internal 10.10.*.* one for
external 208.*.*.*
- we'd accidentally set up 'default gateway' on both
This meant the system was confused as to where to send replies.
I recently had a sever misconfiguration in a slightly different way: the
default route was set to use an eth device that wasn't physically
connected to anything, and the server's primary IP address was also
bound to that device.

The symptoms were that no outgoing connections could be made
successfully, but that incoming connections worked just fine.

This was on a Linux 2.4 kernel, which appears to route the replies
without a problem even with such an egregious misconfiguration: the
kernel appeared to be smart enough to send replies to the "right place"
regardless of the stupidity of the configuration.

In what environment did this default route misconfiguration cause
unreliable responses?

- -chris
will trillich
2009-05-22 19:31:14 UTC
Permalink
On Fri, May 22, 2009 at 2:22 PM, Christopher Schultz
Post by Christopher Schultz
Post by will trillich
- we'd accidentally set up 'default gateway' on both
This meant the system was confused as to where to send replies.
I recently had a sever misconfiguration in a slightly different way: the
default route was set to use an eth device that wasn't physically
connected to anything, and the server's primary IP address was also
bound to that device.
The symptoms were that no outgoing connections could be made
successfully, but that incoming connections worked just fine.
This was on a Linux 2.4 kernel, which appears to route the replies
without a problem even with such an egregious misconfiguration: the
kernel appeared to be smart enough to send replies to the "right place"
regardless of the stupidity of the configuration.
In what environment did this default route misconfiguration cause
unreliable responses?
Windo~1 2003 Enterprise.

It was really weird. For hours at a time, all was well. Packets came,
packets went. Pages were browsed. Then -- poof! -- no traffic at all.
We were originally thinking it was another computer with the same IP
address that had no server, getting all the traffic.

Nope. Just too many default gateways. :)
--
will trillich
"Our only real economic security lies in our power to meet human
needs." -- S.Covey, the 8th Habit
Patrick Herber
2009-05-24 21:00:20 UTC
Permalink
Hello

I've made some more tests and after reading the Book "*Tomcat, The
definitive Guide*" I discovered the existence of a parameter called
"*connectionUploadTimeout*" (below I join the description of this
property taken from this book).
I've changed the configuration of the HTTP connector and now uploading
big files directly on tomcat (without Apache HTTP) works without problems:

<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />

However, if I reset our original configuration with Tomcat behind an
Apache HTTP connected with mod_proxy_ajp (or mod_proxy_http) I get the
same Exception as before (the Upload stops after 30 minutes).

<IfModule mod_proxy_ajp.c>
ProxyRequests Off
ProxyTimeout 3600
<Location / >
ProxyPass ajp://localhost:8009/
ProxyPassReverse ajp://localhost:8009/
</Location>
</IfModule>

<Connector port="8009" protocol="AJP/1.3"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />

Or

<IfModule mod_proxy_http.c>
ProxyRequests Off
ProxyTimeout 3600
<Location / >
ProxyPass http://localhost:8080/
ProxyPassReverse http://localhost:8080/
</Location>
</IfModule>

<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />

I've tried setting the "timeout" parameter in the ProxyPass instruction
to one hour:

ProxyPass ajp://localhost:8009/ timeout=3600

But it did not help...
Do you have any suggestion?

Thanks a lot for your attention and your help
Patrick


Here the description of the three properties copied from the Book
"Tomcat, The definitive Guide" (O'Reilly, Jason Brittain with Ian F.
Darwin). I missed these information in the official Tomcat documentation
(didn't I see it?):

*disableUploadTimeout*
Should Tomcat use the regular connectionTimeout for request socket
connections even for long servlet requests, such as uploads? Setting
disableUploadTimeout to true allows long requests to servlets to
continue without the Connector closing the connection. Setting it to
false means that a longer connection timeout (connectionUploadTimeout's
value) will be used for requests to servlets. Setting it to false means
that the lower connection timeout specified in the connectionTimeout
attribute will be applied to all types of requests.
The default for this attribute is not consistent between Connector
implementations and versions of Tomcat. We strongly suggest that you
explicitly set it to either true or false.

*connectionTimeout*
The Connector may wait a configurable number of milliseconds from the
time the client's request TCP socket is accepted until the request
method line is sent to Tomcat.
The default is 1 minute. 60000

*connectionUploadTimeout*
By default, Connectors keep request socket connections open while Tomcat
processes the request, until the connectionTimeout of 1 minute has
passed. At that point, the Connector will close the socket. But, this
causes trouble if the request was for a long running servlet, such as a
file upload. During requests that map to servlets, Tomcat will use a
longer timeout, specified by the connectionUploadTimeout attribute in
milliseconds.
The default is 300000 milliseconds (5 minutes). 300000
Bill Barker
2009-05-25 00:18:26 UTC
Permalink
Post by Patrick Herber
Hello
I've made some more tests and after reading the Book "*Tomcat, The
definitive Guide*" I discovered the existence of a parameter called
"*connectionUploadTimeout*" (below I join the description of this
property taken from this book).
I've changed the configuration of the HTTP connector and now uploading
<Connector port="80" protocol="HTTP/1.1"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />
However, if I reset our original configuration with Tomcat behind an
Apache HTTP connected with mod_proxy_ajp (or mod_proxy_http) I get the
same Exception as before (the Upload stops after 30 minutes).
<IfModule mod_proxy_ajp.c>
ProxyRequests Off
ProxyTimeout 3600
This looks a lot like 30min ;)
Post by Patrick Herber
<Location / >
ProxyPass ajp://localhost:8009/
ProxyPassReverse ajp://localhost:8009/
</Location>
</IfModule>
<Connector port="8009" protocol="AJP/1.3"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />
Or
<IfModule mod_proxy_http.c>
ProxyRequests Off
ProxyTimeout 3600
<Location / >
ProxyPass http://localhost:8080/
ProxyPassReverse http://localhost:8080/
</Location>
</IfModule>
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="600000"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
redirectPort="8443" />
I've tried setting the "timeout" parameter in the ProxyPass instruction
ProxyPass ajp://localhost:8009/ timeout=3600
But it did not help...
Do you have any suggestion?
Thanks a lot for your attention and your help
Patrick
Here the description of the three properties copied from the Book
"Tomcat, The definitive Guide" (O'Reilly, Jason Brittain with Ian F.
Darwin). I missed these information in the official Tomcat documentation
*disableUploadTimeout*
Should Tomcat use the regular connectionTimeout for request socket
connections even for long servlet requests, such as uploads? Setting
disableUploadTimeout to true allows long requests to servlets to
continue without the Connector closing the connection. Setting it to
false means that a longer connection timeout (connectionUploadTimeout's
value) will be used for requests to servlets. Setting it to false means
that the lower connection timeout specified in the connectionTimeout
attribute will be applied to all types of requests.
The default for this attribute is not consistent between Connector
implementations and versions of Tomcat. We strongly suggest that you
explicitly set it to either true or false.
*connectionTimeout*
The Connector may wait a configurable number of milliseconds from the
time the client's request TCP socket is accepted until the request
method line is sent to Tomcat.
The default is 1 minute. 60000
*connectionUploadTimeout*
By default, Connectors keep request socket connections open while Tomcat
processes the request, until the connectionTimeout of 1 minute has
passed. At that point, the Connector will close the socket. But, this
causes trouble if the request was for a long running servlet, such as a
file upload. During requests that map to servlets, Tomcat will use a
longer timeout, specified by the connectionUploadTimeout attribute in
milliseconds.
The default is 300000 milliseconds (5 minutes). 300000
Caldarale, Charles R
2009-05-25 03:07:02 UTC
Permalink
Subject: Re: Upload stop after 30 minutes: Processing of
multipart/form-data request failed. Stream ended unexpectedly
Post by Patrick Herber
<IfModule mod_proxy_ajp.c>
ProxyRequests Off
ProxyTimeout 3600
This looks a lot like 30min ;)
??? Isn't that more like 60 minutes?

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Patrick Herber
2009-05-25 03:27:03 UTC
Permalink
Post by Patrick Herber
ProxyTimeout 3600
This looks a lot like 30min ;)
IMHO no... it should be 60 seconds * 60 = 1 hour


Regards
Patrick
André Warnier
2009-05-25 09:30:46 UTC
Permalink
Post by Bill Barker
Post by Patrick Herber
ProxyTimeout 3600
This looks a lot like 30min ;)
Does it really ?
Caldarale, Charles R
2009-05-25 16:16:14 UTC
Permalink
Subject: Re: Upload stop after 30 minutes: Processing of
multipart/form-datarequest failed. Stream ended unexpectedly
Post by Bill Barker
Post by Patrick Herber
ProxyTimeout 3600
This looks a lot like 30min ;)
Does it really ?
Maybe he was moving at 0.75c at the time... it's all relative.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Patrick Herber
2009-05-26 09:34:48 UTC
Permalink
Originally I'd put this setting ProxyTimeout 3600, because it seams to
be the only existing timeout setting at proxy's level (togheter with
Timeout and the attribute timeout=xxx of proxypass).

However, removing this setting, putting it after ProxyPass, using
Timeout at VirtualHost level (see:
http://mail-archives.apache.org/mod_mbox/httpd-users/200710.mbox/%***@w032y7.pnet.ch%3E)
does not make any difference...

Do you have any other suggestions?
Thanks a lot again for your help.

Patrick
Mateusz Kijowski
2009-08-04 15:37:56 UTC
Permalink
Hi,


It seems that I am encountering the same or similar problem. I am
getting the same exception using the same proxy setup (Apache httpd ->
mod_proxy_ajp -> AJP Connector -> Apache Tomcat), although I am not
certain that the exception occurs after 30 minutes. The only way to
reproduce this error involved using bandwidth throttler on a Windows
XP client. It also seems that the problem is reproducible only under
IE, but I might be wrong about this. I tried to reproduce the error by
modifying various timeouts, but I did not succeed.

Below are relevant configuration snippets:

<Connector port="8009"

protocol="AJP/1.3" connectionTimeout="120000" maxThreads="1000"
minSpareThreads="50" maxSpareThreads="100" enableLookups="false"
acceptCount="150" address="127.0.0.1"
useBodyEncodingForURI="true"

compression="on"
compressionMinSize="1024"
compressableMimeType="text/html,text/xml"
connectionUploadTimeout="3600000"
disableUploadTimeout="true"

/>

Timeout 600

<VirtualHost example.com>

#[...]

Timeout 3600
ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/
ProxyTimeout 3600

</VirtualHost>

Patrick, did you manage to find the cause? Does anyone else have a
hint what might be the cause?

Thanks for your help,


Mateusz.
André Warnier
2009-08-04 19:04:32 UTC
Permalink
Post by Mateusz Kijowski
<Connector port="8009"
...
Post by Mateusz Kijowski
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
...
May or may not be relevant, but I do not see the above attributes in the
Tomcat AJP Connector docs.
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
and only see disableUploadTimeout in the HTTP Connector.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
Mateusz Kijowski
2009-08-05 10:03:58 UTC
Permalink
Post by André Warnier
May or may not be relevant, but I do not see the above attributes in the
Tomcat AJP Connector docs.
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
and only see disableUploadTimeout in the HTTP Connector.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
André,


Thanks for your reply. Those attributes are taken from polish
translation of "Tomcat. The definitive guide." from O'Reilly. Perhaps
the on-line docs are out of date? Tomcat doesn't complain about them
at startup so I suppose that they are correct. Moreover, I added those
hoping that it would solve the issue so these are most probably not
causing my problems.

Does anybody have any other suggestions? Thanks in advance,


Mateusz.
André Warnier
2009-08-05 12:01:55 UTC
Permalink
Post by Mateusz Kijowski
Post by André Warnier
May or may not be relevant, but I do not see the above attributes in the
Tomcat AJP Connector docs.
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
and only see disableUploadTimeout in the HTTP Connector.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
André,
Thanks for your reply. Those attributes are taken from polish
translation of "Tomcat. The definitive guide." from O'Reilly. Perhaps
the on-line docs are out of date? Tomcat doesn't complain about them
at startup so I suppose that they are correct. Moreover, I added those
hoping that it would solve the issue so these are most probably not
causing my problems.
The experts should be waking up soon, and they will tell us.
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.

In which case you are right, they would not be causing your problem. But
they may give you the impression that you are changing something, while
you aren't.
Christopher Schultz
2009-08-05 13:34:06 UTC
Permalink
André,
Post by André Warnier
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.
I regard both of the above statements as true. What version of Tomcat
does your copy of "Tomcat: The Definitive Guide" cover? Assuming you
have the 2nd Edition, it was written in 2007 and should cover Tomcat 6
configuration as well as 5.5.

You didn't mention which version of Tomcat you're using, so we don't
know which configuration documentation to send you. :(

- -chris
Mateusz Kijowski
2009-08-05 14:33:43 UTC
Permalink
Post by Christopher Schultz
Post by André Warnier
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.
I regard both of the above statements as true. What version of Tomcat
does your copy of "Tomcat: The Definitive Guide" cover? Assuming you
have the 2nd Edition, it was written in 2007 and should cover Tomcat 6
configuration as well as 5.5.
The "Definitive Guide" I have is the second edition, supposedly
covering 6.0. The book doesn't describe HTTP and AJP connectors
separately, instead the attributes in question are both present in the
list of allowed attributes for the Connector config element. The
header of the attribute list says that the list contains attributes
allowed by all Connectors shipped with Tomcat (not specifying any
specific version). That's why I guessed that Tomcat version was
irrelevant.

Again, either the on-line docs are out of date, or the book is wrong.
Post by Christopher Schultz
You didn't mention which version of Tomcat you're using, so we don't
know which configuration documentation to send you. :(
Sorry about that, I am using 6.0.18 and Apache httpd 2.2.11. The
problem still occurs quite regularly, and I can't think of any more
settings to tune.

Thanks for all of your replies,


Mateusz.
Mark Thomas
2009-08-05 14:54:49 UTC
Permalink
Post by Mateusz Kijowski
Post by Christopher Schultz
Post by André Warnier
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.
I regard both of the above statements as true. What version of Tomcat
does your copy of "Tomcat: The Definitive Guide" cover? Assuming you
have the 2nd Edition, it was written in 2007 and should cover Tomcat 6
configuration as well as 5.5.
The "Definitive Guide" I have is the second edition, supposedly
covering 6.0. The book doesn't describe HTTP and AJP connectors
separately, instead the attributes in question are both present in the
list of allowed attributes for the Connector config element.
That is bad. There are significant differences between AJP and HTTP.
Post by Mateusz Kijowski
The
header of the attribute list says that the list contains attributes
allowed by all Connectors shipped with Tomcat (not specifying any
specific version). That's why I guessed that Tomcat version was
irrelevant.
Again, either the on-line docs are out of date, or the book is wrong.
The book is wrong. Whilst the on-line docs aren't perfect they are
always going to be more up to date than a book.
Post by Mateusz Kijowski
Post by Christopher Schultz
You didn't mention which version of Tomcat you're using, so we don't
know which configuration documentation to send you. :(
Sorry about that, I am using 6.0.18 and Apache httpd 2.2.11. The
problem still occurs quite regularly, and I can't think of any more
settings to tune.
As per the advice previously mentioned in this thread. Connect directly
to Tomcat and see if you still get the problem. That would help narrow
things down.

What is your timeout setting for httpd?

Personally, I usually roll out Wireshark / tcpdump at this point to see
exactly what is going on. It'll be a time-out somewhere. You just need
to find out where.

Mark
Caldarale, Charles R
2009-08-05 13:34:26 UTC
Permalink
Subject: Re: Upload stop after 30 minutes: Processing of
multipart/form-data request failed. Stream ended unexpectedly
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.
Correct on both counts.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
Martin Gainty
2009-08-05 13:43:01 UTC
Permalink
any way to incorporate Javadoc AND translations as part of the build for
deutsche?
francais?
polska?
italiano?
norsk?
svenska?

BTW: andre you are awake now so looks like you are one of the early am TC gurus

Martin Gainty
______________________________________________
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni.
Date: Wed, 5 Aug 2009 14:01:55 +0200
Subject: Re: Upload stop after 30 minutes: Processing of multipart/form-data request failed. Stream ended unexpectedly
Post by Mateusz Kijowski
Post by André Warnier
May or may not be relevant, but I do not see the above attributes in the
Tomcat AJP Connector docs.
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
and only see disableUploadTimeout in the HTTP Connector.
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
André,
Thanks for your reply. Those attributes are taken from polish
translation of "Tomcat. The definitive guide." from O'Reilly. Perhaps
the on-line docs are out of date? Tomcat doesn't complain about them
at startup so I suppose that they are correct. Moreover, I added those
hoping that it would solve the issue so these are most probably not
causing my problems.
The experts should be waking up soon, and they will tell us.
All in all, I believe the on-line doc has a bigger chance of being
accurate than the book; and I also believe Tomcat will just ignore
attributes that it does not know.
In which case you are right, they would not be causing your problem. But
they may give you the impression that you are changing something, while
you aren't.
---------------------------------------------------------------------
_________________________________________________________________
Get your vacation photos on your phone!
http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM
Christopher Schultz
2009-08-05 13:38:06 UTC
Permalink
André,
Post by André Warnier
Post by Mateusz Kijowski
<Connector port="8009"
...
Post by Mateusz Kijowski
connectionUploadTimeout="3600000"
disableUploadTimeout="true"
...
May or may not be relevant, but I do not see the above attributes in the
Tomcat AJP Connector docs.
disableUploadTimeout is definitely in the HTTP connector documentation.
The other one does not appear in the 6.0 documentation.

- -chris
Caldarale, Charles R
2009-08-05 13:42:56 UTC
Permalink
Subject: Re: Upload stop after 30 minutes: Processing of
multipart/form-data request failed. Stream ended unexpectedly
disableUploadTimeout is definitely in the HTTP connector documentation.
True, but we're talking about the AJP, not HTTP, connector, and there's no tag in the docs related to upload timeouts for AJP.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-ma
Christopher Schultz
2009-08-05 17:42:29 UTC
Permalink
Chuck,
Post by Caldarale, Charles R
Subject: Re: Upload stop after 30 minutes: Processing of
multipart/form-data request failed. Stream ended unexpectedly
disableUploadTimeout is definitely in the HTTP connector
documentation.
True, but we're talking about the AJP, not HTTP, connector, and
there's no tag in the docs related to upload timeouts for AJP.
Right: I was just pointing out that disableUploadTimeout is at least
relevant /somewhere/, while the other settings seems to be either
fictional or a misprint.

I even checked Tomcat 4.1 (my alma mater), and connectionUploadTimeout
just ain't there.

- -chris
christianjunk
2009-10-19 13:16:26 UTC
Permalink
Is there any solution out now? I'm having the same problems with Tomcat
6.0.18 (Windows) behind an Apache2 webserver, using ProxyPass.

When I connect to Tomcat directly I have no problems and the uploads work
fine.

Regards,
Christian
--
View this message in context: http://www.nabble.com/Upload-stop-after-30-minutes%3A-Processing-of-multipart-form-data-request-failed.-Stream-ended-unexpectedly-tp23660524p25958247.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
Loading...