I installed apache tomcat 6 on my server and created my first index page in the ROOT folder and everything worked perfectly. But as soon as I started to attempt to tweek the page to make it look how I wanted it to I noticed that the changes where not being reflected in the borwser and the old page continues to be displayed. Does anyone know why it does this and how it can be fixed so I can see changes immediately?

asked by ts8550

There are a number of settings which may apply to your situation.

If the file you are editing is a small 'static' file, Tomcat may be caching it in memory. The attribute values of the Context element which govern this are: cacheMaxSize, cacheObjectMaxSize, cacheTTL and cachingAllowed.

You can find more details about their values in the Tomcat Documentation at: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html

If the resource you are editing is a JSP file, then you should check to see if the attributes of org.apache.jasper.servlet.JspServlet in apache-tomcat-6.x/conf/web.xml have been adjusted - it's usual to disable attributes associated with file recompilation during development, before placing the server into production.

Each attribute is well documented in the configuration file, it's worth reading the whole of the standard web.xml to understand more about how Tomcat works.

answered by pidster on August 31, 2010 10:13 AM

Read More

I'm using Tomcat 6 and am having trouble getting large pages to load. We've developed a page for a site that gets generated for specific cities. When I test it on my IDE, it works without a hitch. However, when I deploy the app to our server running tomcat 6, on locations with a small amount of information seem to work. I've isolated that it related to the size of what is being generated. Is there a way to increase the size of the files that tomcat will generate from jsps?

asked by rfrubin

There is a restriction on the size of a compiled method, which is 64kb of bytecode - but this must not be confused with the size of the data output from a method.

I'd expect it to be a low probability that you've run into this restriction, but if you have then it shouldn't be too hard to refactor the JSP to get around it.

From the limited information you provide it's nearly impossible to tell what the likely source of the problem is.  I'd be looking for Exceptions in the Tomcat logs and examining whether the page was failing because it depended on other resources which are unable to deliver large amounts of information in a timely fashion.

If the problem is reproducible then it should be relatively easy to narrow down the portion of the code which causes the problem; even if this means selectively commenting out section of the JSP and testing each part of it separately.

answered by pidster on August 10, 2010 09:31 AM

Read More

asked by Technext

You have a few problems, the cause of them is not entirely clear.

One thing to bear in mind is this: when you're using Apache HTTPD in front of Tomcat, if you can get it working under normal HTTP then configuring HTTPS should be simple.

HTTP and HTTPS in Apache HTTPD are treated as separate VirtualHosts, so it should just be a case of ensuring that whatever configuration you've applied to the HTTP virtual host is also applied to the HTTPS host.

This can be achieved with ease, by placing all of the mod_jk or mod_proxy (in your case) configuration in an external file and using the 'include' mechanism.

The HTTP address you provide is using the port 8080, which Tomcat specifies as the default port for it's own HTTP connector - suggesting that you're not connecting via Apache HTTPD when you make that request.

The ProxyPass statements point both /abc and / to the same path, which is a subpath of the application /abc - this seems unusual.  I'd expect to see the path http://server:8080/abc, without the '/implement' extension, this may be the source of some of the missing images.

The last issue, regarding the message "line 56 Object expected" is likely to be a Javascript problem, possibly caused by a script file experiencing the same 404 as the images.

In order to debug the problem, it would be better to start with a fresh configuration - discard whatever you have so far, or copy it to a backup.

The Fiddler or ieHttpHeader plugins for Internet Explorer will make it easier to examine which resources are, or are not being served correctly.

You will need to examine both the Apache HTTPD and Tomcat access logs to see which server is serving each request and check that the result is the expected one.

Configure the HTTP instance and test it thoroughly before attempting the HTTPS configuration.

answered by pidster on August 5, 2010 08:39 AM

Read More

How many "simultaneous users" can a Tomcat server support and where do I find this setting? I've read on the internet that Tomcat is limited to 15 "simultaneous users" and that Tomcat supports "unlimited numbers" of users. What's the real story?

asked by johnv

Tomcat doesn't have such a setting and you shouldn't trust everything you read on the internet!

A limitation like 15 simultaneous users would make the large scale, high availability Tomcat deployments that are already powering banks, government applications and large corporations completely impossible. On the Apache Tomcat Users mailing list, for example, we see people fairly frequently who are debugging their applications under load tests simulating thousands of concurrent users.

One of the advantages of using software like Tomcat is that it provides the Servlet Spec environment, (which is usually enough to support most applications with a few Apache Commons libraries or the use of frameworks like Struts and Spring), but it's lightweight and uses comparatively little in the way of system resources itself.

The amount of concurrent users will depend on the server hardware (processors, memory), the types of resources being used within the application and what your application is actually doing. A fictional application which generates PDF reports on demand from large amounts of data, taking minutes for each request is going to need substantially more server resources to support a similar number of users to an application which is serving largely static or cached resources.

In Tomcat versions 6.0 and up, the best way to configure the number of threads the Connector uses is via the Executor element. http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html

The default setting for the maxThreads attribute is 200, which should be enough to get most applications started. In fact, in my experience you'll need to add more servers to scale up because of application memory usage before the maxThreads attribute gets too high.

So, to answer each question: Tomcat is not limited to 15 users; it will support however many concurrent users your application(s) can support.

answered by pidster on August 3, 2010 10:02 AM

Read More

How do you gracefully restart Tomcat? It will be good to have a standard way doing this. We created a health check url for the load balancer (e.g. /health). This url returns 200 status to indicate this service is up. There is a prob.txt under tomcat dir. If we delete this file, the health check will start returning 404. Thus, remove this box from load balancer. Wait for 2 to 3 mins before shutting it down the process to ensure all request have been processed.

asked by mcheung610

Tomcat, unlike Apache HTTPD, does not have a graceful restart function, largely because of the consequences of it being an application server rather than a web server.

The restart time for server itself largely depends on how long it takes your application to start up, you should be able to start a fresh Tomcat instance in a few seconds - it's worth noting how long it takes to start up on your system, before you customise the configuration.

Instead of restarting the server, you can restart individual applications, which is nearer to the concept of a graceful restart and wouldn't incur the overhead of restarting all of the applications.

An appropriately secured* Manager application instance in each Host, will enable you to selectively restart an application. Automated requests can be sent to the /manager/text component using the same request structure as the /manager/html component, but with smaller output.

* The Manager application should be secured by adding the RemoteIpValve to it's Context definition, with only the specific IP addresses you'll administer the server from enabled.

answered by pidster on July 30, 2010 07:36 AM

Read More