Asi týden jsem si hrál s J2EE aplikací Westico Visibility Platform a každou chvíli mi aplikace sletěla na OutOfMemoryError. Asi memory leak, řekl jsem si.
Stáhl jsem si tedy NetBeansy (qůli profileru) a začal hledat, kde tesař nechal v paměti díru. Zjistil jsem, že mi permanentně narůstá počet instancí dvou Session Stateless EJB, které volám z MDB ihned po sobě, těsně před ukončením zpracování zprávy. Protože provádím JMS ack ihned po příchodu zprávy, říkal jsem si, že si asi lookup vytvoří nové instance fazolí, ale požadavek neskončí a proto to bobtná. Dlouho jsem trasoval onu Message Driven Beanu, dokud jsem si opravdu nebyl jistý, že požadavek skončil a tudíž GC by měl odstranit "nepotřebné" instance a v poolu by měly zůstat jenom "potřebné". Tak jsem se zaměřil na pool a zjistil následující:
JBoss má oddělené pooly pro MDB a stateless EJB. Pro obejítí klasické Javovské synchronizace používá JBoss ThreadLocal pool. A v tom je právě šutr úrazu. Díky klasickému implicitnímu chování MDB se stane, že každý požadavek je zpracován jiným vláknem a tedy pool pro bezestavové fazole bobtná, přestože má nastaven maximální počet instancí v poolu.
Pokud tedy chcete v JBossu volat stateless EJB z MDB, musíte patřičné bezestavové fazoli nastavit jiný typ poolu. Ideálně org.jboss.ejb3.StrictMaxPool, a to třeba pomocí JBossí anotace @PoolClass, jak je popsáno zde.
Třeba to někomu zachrání kupu nervů.
Příspěvky
Dagblog přesunut na vlastní doménu
před 8 lety
Žádné komentáře:
Okomentovat