In case someone has the same problem, here is what I got from Amazon:
"Thank you for contacting AWS support. The behavior you are seeing is due
to the way ELB HTTP/S listeners work. When many client requests come in,
the ELB will create a number of connections to the backend application
server, and will pipeline the client requests over these connections. This
is optimized for performance reasons, but the client requests are not
mapped 1-to-1 to the backend request. This is why ELB does not notify
Tomcat of a terminated client connection. If you would like to change this
behavior and notify Tomcat of a client connection reset, you can change the
listener type from HTTPS to "SSL (Secure TCP)". To do so, go to you ELB >
Listeners tab and hit Edit. When the listener is set to SSL TCP, all client
connections to ELB are mapped 1-to-1 to the backend, and Tomcat will be
notified if the client disconnects prematurely. This will not affect the
behavior of the rest of your application and HTTPS client requests will
continue to be processed, but ELB will not do the connection pipelining
that is causing your issue. For more information on the difference between
the Listener protocols please see
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html
."
On Thu, Jul 9, 2015 at 3:17 AM, André Warnier <a...@ice-sa.com> wrote:
> 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 <a...@ice-sa.com> 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: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
