Log4j configureAndWatch () plodit tisíce nití

hlasů
2

Takže máme J2EE aplikace pomocí Log4j takhle

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();
     }
}

Tímto způsobem můžeme změnit v reálném čase log úrovni. Velmi užitečné. Většina našich třídách jsou nastaveny stejně jako řídicí jednotky. Používáme singleton vzorem, takže máme jen jednu instanci eash třídy; jedno volání PropertyConfigurator.configureAndWatch () pro každou třídu, jakmile.

Problém: O dvakrát týdně naše AppServer umírá a vytváří heapdump. Používání haldy Analyzer od IBM je vidět, že se zdá, že hodně nití spojených s Log4j:

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

O 30.000 celkem. Tak to je asi důvod náhlého krachu.

  1. Jsme toto nastavení správně?
  2. Co se stane, až všechny ty závity, když se EAR přerozděleny?
Položena 26/08/2009 v 22:57
zdroj uživatelem
V jiných jazycích...                            


4 odpovědí

hlasů
7

Jak často jsou případy CustomerController vytvořeny? Jednou za žádost? Protože se domnívám, že configureAndWatch () bude plodit nové vlákno s každou výzvou.

Také, pokud si nejste vědomi, že Log4J dokumenty varují před používáním této funkce v prostředí J2EE:

Vzhledem k tomu, configureAndWatch zahajuje samostatnou wathdog nit, a protože neexistuje žádný způsob, jak zastavit toto vlákno v log4j 1.2, metoda configureAndWatch je bezpečný pro použití v J2EE prostředí, kde jsou recyklované aplikace.

Vím, že nebudete používat jaro, ale podle mého názoru Spring třída Log4jWebConfigurer má lepší vysvětlení o tom, proč je tato funkce je nebezpečný v J2EE:

POZOR: Log4J je watchdog nit neukončí, dokud VM vypnutí; Zejména to nekončí na LogManager vypnutí. Z tohoto důvodu se doporučuje, aby konfigurační soubor nelze použít pro osvěžení v produkčním prostředí J2EE; hlídací nit se nezastaví na aplikačním vypnutí tam.

Aktualizace: Při pohledu na zdroje Log4J, každé volání configureAndWatch () skutečně vytvořit nové vlákno .

Odpovězeno 27/08/2009 v 03:22
zdroj uživatelem

hlasů
4

Opravdu to, co musíte udělat, je zde použít postup spouštění aplikačního serveru (všechny jsou odlišné) pro inicializaci Log4J systém. Vzhledem k tomu, Log4j spoléhá na statické proměnné, nemůže opravdu pracovat samostatně ve vlastním uchu (to trochu může, ale to bude opravdu záležet na aplikačním serveru). Ve většině případů je konfigurace je ve skutečnosti bude globální pro celý aplikační server.

Musíte si být jisti, že tato metoda PropertyConfigurator.configureAndWatch se nazývá pouze jednou. Jeden způsob, jak to udělat, je dát něco JNDI.

Hodně to bude záležet na tom, co aplikační server vám dává. Například používáme JBoss a Log4J je konfigurován jako část, a stačí změnit soubor log4j.xml zahrnout, jaké jsou vaše tříd potřebují. JBoss zajišťuje, že se provádí dynamicky.

EDIT: Zde jsou uvedeny pokyny pro Websphere vytvořit vlastní službu, a uvnitř, že byste vytvořit konfiguraci Log4J, a udělat si sledování souboru. Pár výhrad. Budete muset přidat log4j.jar do classpath aplikačního serveru sám, takže je k válce nebo ucha (Jsem si jistý, že bude fungovat, tak jako tak) k dispozici, a zvyk služby pravděpodobně nebude pracovat uvnitř ucha.

Zde je alternativa, která bude mít vše, co ve válce nebo ucha, ale na úkor dynamicky načítá změny protokolu.

Odpovězeno 26/08/2009 v 23:22
zdroj uživatelem

hlasů
0

Všechny záznamníky mají stejný konfigurační soubor, takže pokud každá třída, která využívá logger obsahuje tento intialization kód, bude každá configureAndWatch () volání pravděpodobně plodit nový hlídač niti. (IMHO, Log4j by měl vědět lépe a umožňují nanejvýš jeden hlídač vlákno jedno konfiguračního souboru, ale zřejmě se tak nestane)

Odpovězeno 27/08/2009 v 08:46
zdroj uživatelem

hlasů
0

Už jste se podíval na logback, Log4J nástupce? Zabývá se překládka jeho konfiguraci buď ve vláknu nebo přes JMX . Oba přístupy vyhnout se bolesti hlavy způsobené tím, že volá PropertyConfigurator.configureandWatch () nebo DOMConfigurator.configurator. Stejně jako zajímavé, že v závitu přístup povolen prostřednictvím konfiguračního souboru (bez vlastního kódu potřeba).

Odpovězeno 27/08/2009 v 08:34
zdroj uživatelem

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