Apache/Tomcat error - wrong pages being delivered

Could it be the thread-safety of your servlets?

Do your servlets store any information in instance members.

For example, something as simple as the following may cause thread-related issues:

public class MyServlet ... {    private String action;    public void doGet(...) {         action = request.getParameter("action");         processAction(response);    }    public void processAction(...) {         if (action.equals("foo")) {             // send foo page         } else if (action.equals("bar")) {             // send bar page         }     }}

Because the serlvet is accessed by multiple threads, there is no guarantee that the action instance member will not be clobbered by someone elses request, and end up sending the wrong page back.

The simple solution to this issue is to use local variables insead of instance members:

public class MyServlet ... {    public void doGet(...) {         String action = request.getParameter("action");         processAction(action, response);    }    public void processAction(...) {         if (action.equals("foo")) {             // send foo page         } else if (action.equals("bar")) {             // send bar page         }     }}

Note: this extends to JavaServer Pages too, if you were dispatching to them for your views?

Check if your headers allow caching without the correct Vary HTTP header (if you use session cookies, for instance, and allow caching, you need an entry in the Vary HTTP header for the cookie header, or a cache/proxy might serve the cached version of a page intended for one user to another user).

The problem might be not with caching on your web server, but on another layer of caching (either on a reverse proxy in front of your web server, or on a proxy near the users). If the clients are behing a NAT, they might also be behind a transparent proxy (and, to make things even harder to debug, the transparent proxy might be configured to not be visible in the headers).

8 updates of the question later one more issue to use to test/reproduce, albeit it might be difficult (or expensive) for public sites.

You could enable https on the sites. This would at least wipe out any other proxies caches along the way. It'd be bad to see that there are some forgotten loadbalancers or company caches on the way that interfere with your traffic.

For public sites this would imply trusted certificates on the keys, so some money will be involved. For testing self-signed keys might suffice. Also, check that there's no transparent proxy involved that decrypts and reencrypts the traffic. (they are easily detectable, as they can't use the same certificate/key as the original server)