RE: Import file 3gb possible?
I'd imagine the JVM heap would have to be cranked up well over 2GB to handle that too. If you are using the 32 bit JVM, you might not be able to set the heap over 2GB. -Original Message- From: David Kerber [mailto:[EMAIL PROTECTED] Sent: Thursday, June 15, 2006 11:02 AM To: Tomcat Users List Subject: Re: Import file 3gb possible? Terry Orechia wrote: Is it possible to import a large file greater than 3 gigabytes to a tomcat web server? I am running tomcat 4.1 on debian with Tomcat/Apache JK2 Connector . I upload a file using multipart/form data on http Post request to servlet. I have successfully uploaded a file that was just under 2 gb, but am getting page cannot be displayed error when I try to upload a file which is 3.1gb. Is there a limit of 2gb on the size of a POST message in apache2? There is a parameter LimitRequestBody that can be configured in conf.http in apache2 to limit the size of the post message. The value of this parameter can be any number from 0 to 2gb.It is not configured so it is defaulting to 0 which is unlimited. Does unlimited mean their is a max size of 2gb? Is there a way to POST a messeg 2gb so a file greater than 2gb can be uploaded from the desktop to the webserver? I have searched on the web and still do not understand if this can be done? Thanks for your input, Terry What is the file system on the server machine? Some filesystems have a limit of 2GB for a single file. Dave - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
What triggers jspDestroy?
I have a page that renders a very large report using the apache jstl tags. When the page has finished running, my memory usage jumps up 70MB. Even if I force a full garbage collection (verified in my garbage collector log), memory usage does not decrease. There is no data being cached or stored in the user's session, it's simply dumped into the request and rendered by the JSP. I've found that if I un-deploy the war and force a full garbage collection, memory usage drops 70MB. I've also found that after waiting about 30 minutes, the memory is released. When I did memory snapshots before and after running that page, I could still see the page exists in memory (org.apache.jsp.ContactReport_jsp) and appears to be holding on to that 70MB. From what I've read (http://issues.apache.org/bugzilla/show_bug.cgi?id=25623) , it's seems like the memory that is used by the jstl foreach tag is not released until the page is destroyed. I'd like to verify this is truly the case and I'd also like to find out exactly what triggers the call to jspDestroy. Is there a timer, a thread, a memory threshold? Is there something I can/should configure to keep the page from eating up all of that memory for so long? I've tried disabling tag pooling, but that had no effect. Thanks!! _ Bob Damato Cox Target Media Internet Technology Manager Largo, Florida Our greatest glory is not in never falling, but in rising every time we fall. -- Confucius
c:import and session scope in tomcat
I have two webapps. Webapp one contains this JSP x.jsp: -- %@ taglib uri=/c.tld prefix=c % % session.setAttribute(tester, this is a test attribute); % PRE Value from attribute in webapp one: c:out value=${tester} / c:import context=/webapp2 url=/y.jsp / -- Webapp two contains this JSP y.jsp -- %@ taglib uri=/c.tld prefix=c % Value of attribute from webapp two: c:out value=${tester} / -- Under our current web container (servlet exec 4.2) with context sharing enabled, webapp two has access to the session attribute tester from webapp one. When we run this under Tomcat 5.5 with crossContext enabled, webapp two does not have access to that session attribute. Anyone have any idea why? Which one is correct? _ Bob Damato Cox Target Media Internet Technology Manager Largo, Florida Our greatest glory is not in never falling, but in rising every time we fall. -- Confucius