Любые дружеские предложения о том, почему мы можем получать эти 500 статусов от tomcat для загрузки файлов, которая, казалось бы, началась успешно (200 статусов)?
Мы используем ExtendedAccessLogValve для входавсе запросы к нашему серверу tomcat.
Вот шаблон:
# Поля: дата-время, прошедшее время sc-status cs-метод xH (схема) cs (хост) cs-uri-stem cs-uri-query sc (Content-Length) байты c-ip xR (access_metrics_username) xR (access_metrics_openid) xR (access_metrics_userid) xR (access_metrics_sessionid) cs (реферир) cs (пользователь-агент)
# Версия: 2.0
# Программное обеспечение: Apache Tomcat / 7.0.76
Далее приведен пример ответа о состоянии 500 для загрузки файла, которая начала загрузку и завершилась неудачно после отправки 1219416байтов (1,1 мегабайта) данных.
2019-09-24 06:00:14 200.109 500 GET https "www. {HOST_NAME} .org" / api / v1 / archive / request / {UUID} / file / {UUID} api-token = {API_TOKEN} "7600353549" 1219416 xxx.xx.xxx.181 "{USER_NAME}" "{USER_OPENID}" "{USER_UUID}" - "{REFERER}" "Mozilla / 5.0 (Windows NT 6.1;Trident / 7.0;rv: 11.0) like Gecko "
Вот объяснение всех наших полей:
- date
- time
- time-берется, количество времени, которое запрос потребовался от начала до конца
- sc-status, код состояния http
- cs_method, метод запроса http
- xH (схема),используемый протокол http, всегда https для нас
- cs (хост), хост сайта
- cs-uri-stem, запрашиваемый URL
- cs-uri-query, параметры запроса
- sc (Content-Length), количество ожидаемых байтов в ответе
- байтов, количество отправленных байтов
- c-ip, ip-адрес клиента
- xR (access_metrics_username), имя пользователя пользователя
- xR (access_metrics_openid), openid пользователя
- xR (access_metrics_userid), база данных пользователя uuid
- xR (access_metrics_sessionid), значение JSESSIONID
- cs (Referer)
- cs (User-Agent)
Итак, пользователь успешно начал загрузку, чтоОн длился 200,109 секунд и успешно загрузил 1,1 мегабайта данных, а затем что-то случилось, когда этот запрос был ошибочен, и tomcat сообщил об ответе как 500.
Нам не удалось выяснить, что случилось с этим запросомили как его воспроизвести.
Мы попробовали следующее:
- Запустите загрузку, а затем отмените ее из браузера. Журналы доступа содержат код состояния 200 для этого запроса.
- Начал загрузку и переместил файл на диск, с которого tomcat загружал его.
Любые мысли или предложения по поводу того, чточто произойдет, или как воспроизвести эту проблему.
Обновление по вопросам комментариев
В: Есть ли исключения в ваших журналах?
A: Нет. Ноответ более сложный, чем этот ...
Мы фиксируем большинство исключений с помощью фильтра ExcpetionFilter, в котором есть белый список. Это означает, что следующие исключения не зарегистрированы / отправлены по почте команде разработчиков:
- org.apache.catalina.connector.ClientAbortException
- java.net.SocketException
- xxx.xxx.service.security.xxxAccessDeniedException
- org.apache.commons.fileupload.FileUploadBase $ IOFileUploadException
Мы делаем это, поэтому мы не наводняем себя сообщениями об исключениях и потенциально отключить наши почтовые серверы .
Я добавил протоколирование внутри фильтра белого списка, чтобы посмотреть, генерируются ли эти исключения.
Редактировать
Я забылупомяните в первой части письма, что мы на самом деле передаем файлы сами, а не позволяем tomcat сделать эту работу за нас. Довольно сложно объяснить, почему мы это делаем, но мы это делаем.
Для потоковой передачи файла мы используем служебный класс FileCopyUtils из Spring.
Этот вызов окружен try / catch, который просто переворачивает и отбрасывает проверенные исключения с помощью RuntimeException.
try {
FileCopyUtils.copy(new FileInputStream(file), response.getOutputStream());
} catch (FileNotFoundException | IOException e) {
throw new RuntimeException(e);
}
В цепочке вызовов нет других операторов try / catch.