Ошибка Apache/Tomcat - неправильные поставляемые страницы

Это могла быть потокобезопасность Ваших сервлетов?

Сделайте Ваши сервлеты хранят любую информацию в членах экземпляра.

Например, что-то столь же простое как следующее может вызвать связанные с потоком проблемы:

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
         }
     }
}

Поскольку к serlvet получают доступ несколько потоков, нет никакой гарантии, что член экземпляра действия не будет ударен кем-то на запрос elses и закончит тем, что передал неправильную страницу обратно.

Простое решение этой проблемы состоит в том, чтобы использовать локальные переменные insead членов экземпляра:

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
         }
     }
}

Примечание: это расширяется на Страницы JavaServer также, если Вы отправляли им для своих представлений?

8 обновлений вопроса позже еще одна проблема, чтобы использовать для тестирования / воспроизведения, хотя это может быть сложно (или дорого ) для публичных сайтов.

Вы можете включить https на сайтах. Это, по крайней мере, уничтожило бы любые другие кеши прокси на этом пути. Было бы плохо видеть, что есть некоторые забытые балансировщики нагрузки или кэши компании на пути, которые мешают вашему трафику.

Для общедоступных сайтов это подразумевало бы доверенные сертификаты на ключи, так что будут вовлечены некоторые деньги. Для тестирования может быть достаточно самозаверяющих ключей. Кроме того, убедитесь, что не задействован прозрачный прокси, который расшифровывает и повторно шифрует трафик. (их легко обнаружить, поскольку они не могут использовать тот же сертификат / ключ, что и исходный сервер)

Проверьте, позволяют ли Ваши заголовки кэшироваться без корректного Vary HTTP-заголовок (если Вы используете сеансовые куки, например, и позволяете кэшироваться, Вам нужна запись в Vary HTTP-заголовок для заголовка cookie или кэш/прокси мог бы служить кэшированной версии страницы, предназначенной для одного пользователя другому пользователю).

Проблема могла бы быть не с кэшированием на Вашем веб-сервере, а на другом слое кэширования (или на обратном прокси перед Вашим веб-сервером, или на прокси около пользователей). Если клиенты являются behing NAT, они могли бы также быть позади прозрачного прокси (и, для создания вещей еще тяжелее для отладки, прозрачный прокси мог бы быть настроен, чтобы не быть видимым в заголовках).

У меня была эта проблема, и она действительно свела меня с ума. Я не знаю, почему, но я решил его выключающий Поддержание на http.conf

от

KeepAlive на

кому:

KeepAlive прочь

Мое приложение не использует функцию проверки активности, таким образом, это работало очень хорошо на меня.

Попробуйте это:

response.setHeader("Cache-Control", "no-cache"); //HTTP 1.1
response.setHeader("Pragma", "no-cache"); //HTTP 1.0
response.setDateHeader("Expires", 0); //prevents caching at the proxy server

Я не эксперт, но это могла быть некоторая странная проблема Преобразования сетевых адресов?

Взгляните на этот сайт, он описывает проблему с mod_jk. Я наткнулся на ваше сообщение, когда рассматривал очень похожую проблему. В основном исправление заключается в обновлении mod_jk до более новой версии. У меня еще не было возможности внести изменения в наш сервер, но я собираюсь попробовать это завтра и посмотреть, поможет ли это.

http://securitytracker.com/alerts/2009/Apr/1022001.html

Возможно, это вообще не проблема кеширования. Попробуйте увеличить параметр MaxClients в apache2.conf. Если он слишком низкий (по умолчанию 150?), Apache начинает ставить запросы в очередь. Когда он решает обслуживать поставленный в очередь запрос через mod_proxy, он вытаскивает неправильную страницу (или, возможно, он просто вынужден выполнять всю очередь).