___
From: Baldur Dae [baldur@gmail.com]
Sent: Friday, February 26, 2016 4:52 PM
To: Tomcat Users List
Subject: Re: Uploading large files
Hi Chris!
Thank you so much for your quick response. I'll have a look and I'll come
back here with my progress.
2016-02-26 17:30 GMT+01:00 Christopher Schul
Hi Chris!
Thank you so much for your quick response. I'll have a look and I'll come
back here with my progress.
2016-02-26 17:30 GMT+01:00 Christopher Schultz :
> Baldur,
>
> On 2/25/16 4:44 PM, Baldur Dae wrote:
> > I have a Primefaces webapp which lets users upload files up to 50MB and
> >
Baldur,
On 2/25/16 4:44 PM, Baldur Dae wrote:
> I have a Primefaces webapp which lets users upload files up to 50MB and
> saves posted files into Alfresco (located in another tomcat machine). I've
> successfully configured it to avoid Heap exceptions but it is very slow
> and has a huge impact
Hi all,
I have a Primefaces webapp which lets users upload files up to 50MB and
saves posted files into Alfresco (located in another tomcat machine). I've
successfully configured it to avoid Heap exceptions but it is very slow
and has a huge impact in CPU load.
Basically, the configuration ha
Setting maxSwallowSize="-1" worked. I didn't need maxPostSize at all.
Thanks Konstantin.
On Fri, Aug 29, 2014 at 2:52 PM, Konstantin Kolinko
wrote:
> 2014-08-29 20:19 GMT+04:00 Clint Shank :
> > I was wondering whether anyone out there is seeing a problem uploadi
2014-08-29 20:19 GMT+04:00 Clint Shank :
> I was wondering whether anyone out there is seeing a problem uploading
> large files using Tomcat 8.0.9 and greater (same issue in 8.0.11).
>
> The context is that I'm running Sonatype Nexus in Tomcat. When I do an
> "mvn dep
I was wondering whether anyone out there is seeing a problem uploading
large files using Tomcat 8.0.9 and greater (same issue in 8.0.11).
The context is that I'm running Sonatype Nexus in Tomcat. When I do an
"mvn deploy" on a smaller project, things work. We I do a "mv
On 5/29/2013 1:29 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 5/29/13 2:00 PM, Mark Eggers wrote:
On 5/29/2013 10:48 AM, Mohit Anchlia wrote:
I am looking for a general advice on uploading large files. I am
currently thinking that we do it on our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 5/29/13 2:00 PM, Mark Eggers wrote:
> On 5/29/2013 10:48 AM, Mohit Anchlia wrote:
>> I am looking for a general advice on uploading large files. I am
>> currently thinking that we do it on our API and have clients
>>
On 5/29/2013 10:48 AM, Mohit Anchlia wrote:
I am looking for a general advice on uploading large files. I am currently
thinking that we do it on our API and have clients chunk it in multiple
pieces and send it to the server.
I could try http chunk based transfer but only think I am unsure of is
I am looking for a general advice on uploading large files. I am currently
thinking that we do it on our API and have clients chunk it in multiple
pieces and send it to the server.
I could try http chunk based transfer but only think I am unsure of is if
on the server the entire content is going
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sahana,
On 8/22/12 10:31 AM, Sahana Voleti wrote:
> Yes. I have tried with Chrome and Opera David. Firefox n Explorer
> just fail instantly after looking at the file size over 2GB.
FF has a (recently-fixed) bug where it cannot properly upload files
l
2012/8/22 Sahana Voleti :
> Sir,
> despite trying configuring in access log valves if the same error message
> persists then there must be some bug.
The access log valve would not fix an error for you. It is there to
help you diagnose one.
Back to basics: do you know how file upload works? What
Yes. I have tried with Chrome and Opera David. Firefox n Explorer just fail
instantly after looking at the file size over 2GB.
On Wed, Aug 22, 2012 at 7:58 PM, David kerber wrote:
> Bug, yes, but it sounds to me like the bug is more likely on the client
> end, since the common component of the f
Bug, yes, but it sounds to me like the bug is more likely on the client
end, since the common component of the failing test is the windows
client; the server side seems to be fine on both Windows and Linux.
Have you tried different browsers on the windows machine yet?
On 8/22/2012 10:16 AM,
Sir,
despite trying configuring in access log valves if the same error message
persists then there must be some bug. It beautifully uploads from
a Linux to a windows and Linux machine to linux machine(for over 10GB file
size) but using windows machine as a client it just doesn't upload files
above
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sahana,
On 8/21/12 9:49 AM, Sahana Voleti wrote:
> I have tried all the techniques that we have discussed and yet I
> get the following error:
>
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
>
>
Processing o
> f multipart/for
I have tried all the techniques that we have discussed and yet I get the
following error:
org.apache.commons.fileupload.FileUploadBase$IOFileUploadException:
Processing o
f multipart/form-data request failed. Stream ended unexpectedly
org.apache.commons.fileupload.FileUploadBase$IOFileUploadExcept
can you give me a sample code using content length?
On Mon, Aug 20, 2012 at 5:38 PM, Konstantin Kolinko
wrote:
> 2012/8/20 Sahana Voleti :
> > The documentation is fine but how do you use content length there?
> >
>
> I am logging the value of the "content-length" header.
>
> What that header mea
2012/8/20 Sahana Voleti :
> The documentation is fine but how do you use content length there?
>
I am logging the value of the "content-length" header.
What that header means is defined in the HTTP protocol specification.
> On Mon, Aug 20, 2012 at 5:10 PM, Sahana Voleti
> wrote:
>
>> Is there a
The documentation is fine but how do you use content length there?
On Mon, Aug 20, 2012 at 5:10 PM, Sahana Voleti
wrote:
> Is there any size limitations fr this apache commons upload? Also is there
> any standalone application I can use?
> I think there is some problem in parsing because of which
Is there any size limitations fr this apache commons upload? Also is there
any standalone application I can use?
I think there is some problem in parsing because of which I am getting
multipart/formdata request failed.
On Mon, Aug 20, 2012 at 5:03 PM, Konstantin Kolinko
wrote:
> 2012/8/20 Sahana
2012/8/20 Sahana Voleti :
> Konstantin Kolinko,
> U mentioned these steps in your mail:
> 1. Read documentation for AccessLogValve.
> 2. Use a text editor to edit server.xml file (for the global access
> log) or the META-INF/context.xml file of your web application (for
> your webapp's access log).
2012/8/20 Sahana Voleti :
> Also in my localhost logs in tomcat 7.0.29. It is logging like this:
> 192.168.2.67 - - [20/Aug/2012:13:32:20 +0530] "(¬û>Ñ¿¿?? «ÊR˱{fÔb²¹? æè
> 5í?&º Ù³,µj\< ´?? }b y* Ý?ÀB5ÅÖ8añ¹¶i? ùÇ Z;?ÐÀû#pÌ8
>>ûæ ý5Å *1éIEWç?[?Y°U?ïs,5tÕù )?WÆ?iU¼??/µ£kîUð$?+º&05
> | 7Î ¾ÒL«W
about 10GB) using
>> > the Apache commons upload. I have followed the steps properly,
>> > increased the java heap size and the maxPostSize in tomcat (I am
>> > using tomcat version 7.0.29). Also I am using Windows XP , 2GB RAM
>> > machine.
>>
>> I&#
AM
> > machine.
>
> I'm curious as to why you changed your heap settings? If you are
> uploading large files, you ought to be using disk-based data caching
> so you don't need a big heap.
>
> What did you set your heap size to?
>
> - -chris
> -BEGIN PGP SI
cat (I am
> using tomcat version 7.0.29). Also I am using Windows XP , 2GB RAM
> machine.
I'm curious as to why you changed your heap settings? If you are
uploading large files, you ought to be using disk-based data caching
so you don't need a big heap.
What did you set you
ailto:knst.koli...@gmail.com]
> Sent: Viernes, 17 de Agosto de 2012 08:56 a.m.
> To: Tomcat Users List
> Subject: Re: Problem with uploading large files
>
> 2012/8/17 Sahana Voleti :
> > Konstantin Kolinko,
> > You mentioned the following in your mail:
> > "Yo
I wonder if you are downloading to a FAT formattted drive which has a limit of
4GB per file.
-Original Message-
From: Konstantin Kolinko [mailto:knst.koli...@gmail.com]
Sent: Viernes, 17 de Agosto de 2012 08:56 a.m.
To: Tomcat Users List
Subject: Re: Problem with uploading large files
2012/8/17 Sahana Voleti :
> Konstantin Kolinko,
> You mentioned the following in your mail:
> "You can add the following: "%{content-length}i" to your Access Log
> Valve configuration to log the Content-Length header of the incoming
> request."
> Can you elaborate as to how to make this change.
1.
Konstantin Kolinko,
You mentioned the following in your mail:
"You can add the following: "%{content-length}i" to your Access Log
Valve configuration to log the Content-Length header of the incoming
request."
Can you elaborate as to how to make this change.
Regards,
Sahana
On Fri, Aug 17, 2012 at
Ognjen Blagojevic , Konstantin Kolinko,
By unsuccessful I mean that the file fails to upload. Following
the Apache commons upload guidelines, the data first comes in chunks into a
temp directory and after all the data is collected there it saves it in
the permanent directory. In my case, data comes
2012/8/17 Sahana Voleti :
> Hello list,
>
> I am trying to upload really large files (size about 10GB) using
> the Apache commons upload. I have followed the steps properly, increased
> the java heap size and the maxPostSize in tomcat (I am using tomcat version
> 7.0.29). Also I am using Wind
Sahana,
On 17.8.2012 14:33, Sahana Voleti wrote:
I am trying to upload really large files (size about 10GB) using
the Apache commons upload. I have followed the steps properly, increased
the java heap size and the maxPostSize in tomcat (I am using tomcat version
7.0.29). Also I am using W
Hello list,
I am trying to upload really large files (size about 10GB) using
the Apache commons upload. I have followed the steps properly, increased
the java heap size and the maxPostSize in tomcat (I am using tomcat version
7.0.29). Also I am using Windows XP , 2GB RAM machine. Here is wha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 7/11/2011 4:54 PM, André Warnier wrote:
> I think that you need to scroll back in this thread (to July 8), and
> re-read an answer which Charles provided to a previous question of
> mine.
>
> A partial answer resides in this property, whic
Sai Pullabhotla wrote:
A little more info on the
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK system
property:
The last time I said that the above property is keeping the session
alive, I was only partially correct. The way it is working is -
session is kept alive for the duration
I agree. At this point, I'm not so concerned about the Firefox issue.
I will start a separate thread on it later. I still would like to get
some help on keeping the session alive for the duration of the
configured timeout, after a response is sent for a large request. Any
ideas will be greatly appr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
André,
On 7/11/2011 3:59 PM, André Warnier wrote:
> It seems like there are two quite different issues/discussions going
> on in this same thread, with the same subject line. It is a bit
> confusing, even if originally they relate to the same problem.
It seems like there are two quite different issues/discussions going on in this same
thread, with the same subject line.
It is a bit confusing, even if originally they relate to the same problem.
Would it not be better to split this ?
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sai,
On 7/11/2011 9:29 AM, Sai Pullabhotla wrote:
> I took the threaddump and found that Tomcat's http service thread is
> still blocked on the read from the client after we called the
> forward method. At least, that's how I interpreted this, but be
A little more info on the
org.apache.catalina.session.StandardSession.ACTIVITY_CHECK system
property:
The last time I said that the above property is keeping the session
alive, I was only partially correct. The way it is working is -
session is kept alive for the duration of the upload. The respo
Thanks, Chris!
I took the threaddump and found that Tomcat's http service thread is
still blocked on the read from the client after we called the forward
method. At least, that's how I interpreted this, but below is the
particular thread's dump:
"http-443-1" daemon prio=6 tid=0x4c20b000 n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sai,
On 7/9/2011 8:55 AM, Sai Pullabhotla wrote:
> I added the system property
> org.apache.catalina.session.StandardSession.ACTIVITY_CHECK and set
> it to true, and it appears to be preventing the session timeout.
Glad to see it's working out for y
e:
>> From: André Warnier [mailto:a...@ice-sa.com]
>> Subject: Re: Uploading large files and session timeout
>
>> The do this cleanly, the servlet would need to call
>> HttpSession.getMaxInactiveInterval() at the beginning,
>> to save the existing value, then cal
> From: André Warnier [mailto:a...@ice-sa.com]
> Subject: Re: Uploading large files and session timeout
> The do this cleanly, the servlet would need to call
> HttpSession.getMaxInactiveInterval() at the beginning,
> to save the existing value, then call
> HttpSession.setM
Caldarale, Charles R wrote:
From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
Subject: Re: Uploading large files and session timeout
As far as I know, the session's lastAccessTime gets updated on each
request from the client (by the container), and there is no public API
to u
> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
> Subject: Re: Uploading large files and session timeout
> As far as changing the session timeout from the servlet, I do not
> think it works well when multiple uploads are going simultaneously
> under one session,
o offer.
Sai Pullabhotla
On Fri, Jul 8, 2011 at 2:20 PM, Caldarale, Charles R
wrote:
>> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
>> Subject: Re: Uploading large files and session timeout
>
>> As far as I know, the session's lastAccessTime gets updated o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sai,
On 7/8/2011 10:25 AM, Sai Pullabhotla wrote:
> If the upload takes longer then the session timeout, the session gets
> invalidated right after the upload. Tis means no further requests are
> accepted unless the user logs back in. Is this the expe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chuck,
On 7/8/2011 3:20 PM, Caldarale, Charles R wrote:
>> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
>> Subject: Re: Uploading large files and session timeout
>
>> As far as I know, the session's last
> From: Sai Pullabhotla [mailto:sai.pullabho...@jmethods.com]
> Subject: Re: Uploading large files and session timeout
> As far as I know, the session's lastAccessTime gets updated on each
> request from the client (by the container), and there is no public API
> to update
gt;> We have an application that uploads files using a Servlet deployed in
> >> Tomcat 6. While this works most of the times, occasionally we run into
> >> issues uploading large files. If the upload takes longer then the
> >> session timeout, the session gets inva
:
>>
>> We have an application that uploads files using a Servlet deployed in
>> Tomcat 6. While this works most of the times, occasionally we run into
>> issues uploading large files. If the upload takes longer then the
>> session timeout, the session gets invalidated right af
ile this works most of the times, occasionally we run into
> issues uploading large files. If the upload takes longer then the
> session timeout, the session gets invalidated right after the upload.
> Tis means no further requests are accepted unless the user logs back
> in. Is this the
Sai Pullabhotla wrote:
We have an application that uploads files using a Servlet deployed in
Tomcat 6. While this works most of the times, occasionally we run into
issues uploading large files. If the upload takes longer then the
session timeout, the session gets invalidated right after the
We have an application that uploads files using a Servlet deployed in
Tomcat 6. While this works most of the times, occasionally we run into
issues uploading large files. If the upload takes longer then the
session timeout, the session gets invalidated right after the upload.
Tis means no further
57 matches
Mail list logo
