Log4j configureAndWatch () desova milhares de tópicos

votos
2

Portanto, temos a nossa aplicação J2EE usando Log4j como este

public class CustomerController 
{
    private static Logger logger = Logger.getLogger(CustomerController.class);

     public CustomerService customerservice = null;

     public CustomerController() throws Exception 
     {
           PropertyConfigurator.configureAndWatch(c:\log4j.property, 50000);

            customerservice = ServiceManagerSingleton.getCustomerServiceInstance();
     }
}

Desta forma, podemos mudar o tempo real em nível de log. Muito conveniente. A maioria de nossas classes são configurados como este controlador. Usamos o singleton-padrão de modo que temos apenas uma instância da classe EASH; uma chamada para PropertyConfigurator.configureAndWatch () para cada classe, uma vez.

O problema: Sobre duas vezes por semana a nossa appserver morre e cria um heapdump. Usando Heap Analyzer da IBM, podemos ver que parece haver um monte de tópicos relacionados com Log4j:

 808 (0%) [200] 9 org/apache/log4j/PropertyWatchdog 0x14282ad8

Cerca de 30.000 no total. Portanto, esta é provavelmente a razão para a queda súbita.

  1. Estamos essa configuração corretamente?
  2. O que acontece com todos esses tópicos quando a orelha é reimplantado?
Publicado 26/08/2009 em 22:57
fonte usuário
Em outras línguas...                            


4 respostas

votos
7

Quantas vezes são casos CustomerController criado? Uma vez por pedido? Porque eu acredito que configureAndWatch () irá gerar um novo segmento com cada chamada.

Além disso, se você não está ciente, os docs log4j alertam contra o uso desse recurso em um ambiente J2EE:

Porque o configureAndWatch lança um fio wathdog separado, e porque não há nenhuma maneira de parar esta discussão em log4j 1.2, o método configureAndWatch não é seguro para uso em ambientes J2EE onde as aplicações são reciclados.

Eu sei que você não está usando Spring, mas na minha opinião o Log4jWebConfigurer classe Primavera tem uma melhor explicação sobre por que esse recurso é perigoso em J2EE:

AVISO: fio de cão de guarda do Log4j não termina até que VM desligamento; Em particular, ela não termina em LogManager desligamento. Portanto, recomenda-se não usar arquivo de configuração refrescante em um ambiente J2EE produção; o fio watchdog não iria parar no desligamento aplicativo lá.

Update: Olhando fonte log4j, cada chamada para configureAndWatch () , de fato, criar um novo segmento .

Respondeu 27/08/2009 em 03:22
fonte usuário

votos
4

Realmente o que você precisa fazer aqui é usar o procedimento de inicialização do seu servidor de aplicativos (eles são todos diferentes) para inicializar o sistema log4j. Porque Log4j depende de variáveis ​​estáticas, ele realmente não pode trabalhar de forma independente em seu próprio ouvido (que tipo de pode, mas que realmente vai depender do servidor de aplicativos). Na maioria dos casos, a configuração é realmente vai ser global para todo o servidor de aplicativos.

Você precisa ter certeza de que o método PropertyConfigurator.configureAndWatch só é chamado uma vez. Uma maneira de fazer isso é colocar algo em JNDI.

Um monte de que isso vai depender do que o servidor de aplicativos está lhe dando. Por exemplo, usamos JBoss, e Log4J é configurado como parte dela, e você apenas muda o arquivo log4j.xml para incluir o que suas classes precisa. JBoss garante que ele é feito de forma dinâmica.

EDIT: Aqui estão as instruções para Websphere para criar um serviço personalizado e interior que você iria criar sua configuração Log4J, e fazer o seu acompanhamento do arquivo. Um par de advertências. Você vai ter que adicionar o log4j.jar ao classpath do servidor de aplicativos em si, de modo que ele está disponível para a guerra ou na orelha (eu tenho certeza que irá funcionar, pelo menos), eo serviço personalizado irá provavelmente não trabalhar dentro do ouvido.

Aqui é uma alternativa que irá manter tudo na guerra ou na orelha, mas à custa de carregamento dinâmico de mudanças de log.

Respondeu 26/08/2009 em 23:22
fonte usuário

votos
0

Todos os madeireiros compartilham o mesmo arquivo de configuração, por isso, se cada classe que usa um registrador contém este código intialization, cada chamada configureAndWatch () provavelmente irá gerar um novo segmento observador. (IMHO, Log4j deve saber melhor e permitem, no máximo, um segmento observador per arquivo de configuração, mas aparentemente isso não acontecer)

Respondeu 27/08/2009 em 08:46
fonte usuário

votos
0

Você já olhou para logback, sucessor log4j? Trata-se de recarregar sua configuração, quer no fio ou via JMX . Ambas as abordagens evitar as dores de cabeça causadas pelo telefone PropertyConfigurator.configureandWatch () ou DOMConfigurator.configurator. Assim como curiosamente, a abordagem in thread habilitado através de um arquivo de configuração (sem código personalizado necessário).

Respondeu 27/08/2009 em 08:34
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more