Hi,*The below was originally sent to the Tomcat users mailing list. Since then, we've discovered that the problem DOES NOT occur when we use apache 1.3, so we have moved all our sites back to this version. It is also not limited to PDFs apparently, but happens with all files. The PDFs just happened to be quite large (12MB), so it's more noticeable.
However, we would still like to know if anyone has as resolution for the issue we were experiencing.
------------------------------------------------------------------------------------------------We're having some difficulties with PDFs being served by our intranet. The Intranet is served by Tomcat (5.5.9), via Apache (2.0.54), using mod_jk 1.2.4. This server was set up in the fairly recent past as a replacement for a much older server running apache 1.3.x, tomcat 4.1 and an older version of mod_jk (not sure which one exactly).
The problem is that the PDFs take AGES to download to client machines when they are accessed. This is in contrast to the old server, where there was no delay problem at all in serving exactly the same documents.
The troubleshooting we've performed so far includes:- bypassing apache altogether to access the PDFs via tomcat. The PDFs accessed in this fashion downloaded with NO delay.
- compiling and installing the latest mod_jk connector (1.2.6) and testing this with a test copy of apache (2.0.54) and the same copy of tomcat. This didn't solve the problem.
- using the older mod_jk connector from the old server. The connector worked ok, but the documents were still served really slowly
I should point out that we need to serve these PDFs via tomcat, as we are using a proprietary java library which authenticates users with our central auth server. If we serve the PDFs directly via apache, they will be able to download the PDFs without being authenticated. We could also change the links to the PDFs to serve them via tomcat directly, but we'd then have to allow access to a different port through our border firewall, which is not a popular option as we don't need to serve anything else in this way.
The mod_jk configuration in our tomcat's server.xml file is included below: <Connector port="8080" redirectPort="8443" minSpareThreads="25" connectionTimeout="20000" maxThreads="150" maxSpareThreads="75" maxHttpHeaderSize="8192"> </Connector> <Connector port="8009" redirectPort="8443" debug="0" enableLookups="false" protocol="AJP/1.3"> </Connector>I added the following directives to the first <Connector> tag above, but the problem still occurred:
disableUploadTimeout="false" enableLookups="false" acceptCount="10" secure="false" maxKeepAliveRequests="100" tcpNoDelay="true" useURIValidationHack="false" compression="off" connectionLinger="-1" tomcatAuthentication="true" connectionUploadTimeout="300000" serverSocketTimeout="0" bufferSize="2048" proxyPort="0" Our workers.properties file: # workers.properties.minimal - # # This file provides minimal jk configuration properties needed to # connect to Tomcat. # # The workers that jk should create and work with # workers.tomcat_home=/usr/local/tomcat5 workers.java_home=/usr/local/jdk worker.list=ajp13w # # Defining a worker named ajp13w and of type ajp13 # Note that the name and the type do not have to match. # worker.ajp13w.type=ajp13 worker.ajp13w.host=localhost worker.ajp13w.port=8009 worker.ajp13w.cachesize=10 worker.ajp13w.cache_timeout=600 worker.ajp13w.socket_keepalive=1 worker.ajp13w.socket_timeout=300Does anyone have any suggestions, or even better, solutions to this problem? It's driving us a bit spare. I've also tried this with the latest version of Tomcat (5.5.12), but the same problem still occurs.
Thanks, Guy -- Guy Knights Computer Systems Officer Library Systems QUT Victoria Park Road, Kelvin Grove Ph: (617) 3864 3350 Fax: (617) 3864 5539 Email: g.knights@xxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|