мучает одна проблема. непонятно почему зависает JSP страница.
зависает при условии:
— если в нижеписаном фрагменте отработает metka1
— если внутри геттера произойдет исключение, когда Config используется как bean
jstack показывает блок в waiting to lock <0x0917fd88> (a org.apache.tomcat.util.log.SystemLogHandler)
никто не может объяснить почему происходит такая беда ?
очень неприятно осознавать, что такое может случится на production-е.
ms windows7
netbeans 6.9.1.
tomcat 6.0.26
jdk 1.6.0_20
класс Config
package package1;
import java.util.logging.Level;
import java.util.logging.Logger;
import org.apache.commons.configuration.ConfigurationException;
import org.apache.commons.configuration.XMLConfiguration;
public class Config {
public volatile static Config instance;
XMLConfiguration xml = null;
public Config() {
}
private Config(String configFile) {
try {
xml = new XMLConfiguration(configFile);
} catch (ConfigurationException ex) {
metka1:// Exception точно произойдет
xml = null;
Logger.getLogger(Config.class.getName()).log(Level.SEVERE, null, ex);
}
}
/**
* Get the value of instance
*
* @return the value of instance
*/public static Config getInstance() {
if (instance == null)
{
synchronized (Config.class)
{
if (instance == null)
{
instance = new Config ("file not found");
}
}
}
}
public String getServerName ()
{
return getInstance().xml.getString("serverName");
}
}
http-8084-1 уверенно дампит данные в лог. Остальные все его ждут. Throwable синхронизируется по PrintStream для того чтобы stacktrace записался в лог целостно, а не вперемещку с другими исключениями.
В вашем дампе всё упирается в UserFilter, про приведенный конфиг нет ни слова.
Здравствуйте, Blazkowicz, Вы писали:
B>http-8084-1 уверенно дампит данные в лог. Остальные все его ждут. Throwable синхронизируется по PrintStream для того чтобы stacktrace записался в лог целостно, а не вперемещку с другими исключениями. B>В вашем дампе всё упирается в UserFilter, про приведенный конфиг нет ни слова.
Возможно у вас Throwable.printStackTrace() используется интенсивно, что и создаёт узкое место. Используйте нормальный логгер вместо этого.
> http-8084-1 уверенно дампит данные в лог.
http-8084-1 — завис первым
при вызове printStackTrace внутри фильтра, почему то зависает запись в поток
это происходит только в случае, если отработала metka1
B> Используйте нормальный логгер вместо этого.
да, видимо какая то несовместимость в логгерах
меня беспокоит следующее соображение: так как причина явления не выяснена, могут быть большие затруднения если какая нить сторонняя библиотека использует подобный printStackTrace
Здравствуйте, phront, Вы писали:
>> http-8084-1 уверенно дампит данные в лог. P>http-8084-1 — завис первым P>при вызове printStackTrace внутри фильтра, почему то зависает запись в поток P>это происходит только в случае, если отработала metka1
Вероятно, потому что UserFilter падает без конфигурации. Разве нет?
B>> Используйте нормальный логгер вместо этого. P>да, видимо какая то несовместимость в логгерах
Какая ещё не совместимость? Не используйте метод printStackTrace в продакшне. И покажите исходники вашего фильтра. Очевидно что проблема в нем, он просто всегда падает, если конфигурация отсутствует.
B>Вероятно, потому что UserFilter падает без конфигурации. Разве нет? B>Какая ещё не совместимость? Не используйте метод printStackTrace в продакшне. И покажите исходники вашего фильтра. Очевидно что проблема в нем, он просто всегда падает, если конфигурация отсутствует.
Здравствуйте, phront, Вы писали:
B>>Вероятно, потому что UserFilter падает без конфигурации. Разве нет? B>>Какая ещё не совместимость? Не используйте метод printStackTrace в продакшне. И покажите исходники вашего фильтра. Очевидно что проблема в нем, он просто всегда падает, если конфигурация отсутствует.
P>http://pastebin.com/M4SXF5zZ
Уберите t.printStackTrace() совсем. И смотрите какие исключения выводятся на страницу или в лог. Я не вижу никаких зависаний. У вас просто постоянно система выбрасывает исключения, на которые вы не смотрите.
