tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat unaware that connection has been dropped
Date Thu, 09 Jul 2015 10:17:57 GMT
Tecno Brain wrote:
> Hi Andre,
> These files can be huge (for a few of my clients). It can take more than an
> hour for the entire file to be generated.

Then you also have to take into account that when the browser issues a request to the 
server, it expects *some* answer within a maximum of about 5 minutes maximum.  If it 
doesn't get that, the browser will drop the connection and display a message like "the 
server is not responding"...

> I just didn't want to save them. I was expecting that if the file was too
> big, the process would just be aborted. As it is now, my webapp keeps
> working eventhough no browser is receiving the data.
> I guess I will have to save them (In S3) an notify my client via e-mail
> when the file is available.

I am not even sure that in such a case, having the file be generated by a webserver webapp

is the best design.  It means that when the browser issues such a request, one of the 
webserver's threads/children is busy with that request for a very extended period of time,

unable to do anything else.  That looks like an ideal case for a Denial of Service e.g.

You may want to re-examine the whole principle of this thing.
In some restaurants, if you want some special dish that take a long time to prepare, you 
have to order it in advance; you can't just walk in and order it from the menu.

> I'll also ask Amazon about it.
> Thank you,
> -Jorge
> On Thu, Jul 9, 2015 at 2:06 AM, André Warnier <> wrote:
>> Tecno Brain wrote:
>>> I am running Tomcat 8.0.20 in Ubuntu with Java 1.8u45
>>> This server runs in Amazon EC2 behind an ELB (load balancer), although the
>>> cluster size is just one server.
>>> My application allows to download some data in CSV format.
>>> The CSV data is generated on the fly, and there is no way to known in
>>> advance the size of the response. So, the data is an attachment.
>>>  response.setContentType("text/csv;charset=utf-8");
>>>  filename = "data.csv"
>>>  response.setHeader("Content-Disposition", "attachment; filename=\"" +
>>> filename + ".csv\"");
>>> The download starts immediately but after 100 MB the browser stopped
>>> received data -my internet connection was not the best-, so I canceled the
>>> download as it was not progressing anymore.
>>> Nevertheless, my web app keeps generating the CSV data, unaware that the
>>> connection has been dropped. I was expecting that my code would get an
>>> IOException when writing to the servlet OutputStream (which was wrapped by
>>> a BufferedOutputStream and wrapped by an OutputStreamWriter).
>>> Is this a problem I can solve through the configuration of the NIO
>>> connector ?
>>> Or is this a problem of Amazon ELB that still consumes the stream even
>>> though it can't be forwarded to the browser anymore?
>> Yes, that kind of thing.  There may also be load-balancers, proxies,
>> gateways, etc. between Tomcat and the end-user browser.
>> As long as Tomcat itself is able to write to that connection, there is no
>> way for an application within Tomcat, to even find out that the ultimate
>> client has gone away.
>>> I don't remember having this problem when working with Apache HTTP as the
>>> load balancer. If I remember correctly, I would get an error indicating
>>> that the client closed the connection.
>> Yes, in some cases, because then there was less buffering in-between.
>>> Any pointers are appreciated.
>> If your generated files are really that big, I would suggest that the
>> Tomcat side writes them to disk to a temporary file, and then returns to
>> the client a short response, with a link where it can retrieve that file.
>> Then there could be a separate cleanup procedure, which cleans up such
>> temporary files when they are more than a certain age.
>>  -Jorge
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message