Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of aw@ice-sa.com designates
 81.169.250.120 as permitted sender)
Message-ID: <559E4A55.60609@ice-sa.com>
Date: Thu, 09 Jul 2015 12:17:57 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Tomcat unaware that connection has been dropped
References: 
 <CANj+m=iKKy=PE4X5f=NVZ_nCc+zms+7Q=EHjAZeOdma519aARw@mail.gmail.com>
	<559E39A7.3010204@ice-sa.com>
 <CANj+m=gnS8G-Nd+VZFkXXzDjoGz9Ln1BS3urCicvQX-pWSCeRA@mail.gmail.com>
In-Reply-To: 
 <CANj+m=gnS8G-Nd+VZFkXXzDjoGz9Ln1BS3urCicvQX-pWSCeRA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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 <aw@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org