[Struts] Tomcat crash bij redeploy

[Johan.B]

Even een kleine situatieschets:
Samen met een collega ontwikkel ik op een linux tomcat bak.
We hebben beide een aparte webapp.
We gebruiken een ant script.
Met een sftp module plaatsen we de war op de server.
Momenteel maken we gebruik van autodeploy.

Wanneer mijn collega dit doet is er (in 95% van de gevallen) geen probleem. Wanneer ik dit doe is er (in 95% van de gevallen) wel een probleem. Wanneer ik redeploy crashed tomcat met volgende foutmelding:

Java:

HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException
    org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:286)
    org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
    org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

root cause

java.lang.NullPointerException
    org.apache.log4j.spi.LocationInfo.<init>(LocationInfo.java:104)
    org.apache.log4j.spi.LoggingEvent.getLocationInformation(LoggingEvent.java:191)
    org.apache.log4j.helpers.PatternParser$LocationPatternConverter.convert(PatternParser.java:483)
    org.apache.log4j.helpers.PatternConverter.format(PatternConverter.java:64)
    org.apache.log4j.PatternLayout.format(PatternLayout.java:503)
    org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:301)
    org.apache.log4j.DailyRollingFileAppender.subAppend(DailyRollingFileAppender.java:358)
    org.apache.log4j.WriterAppender.append(WriterAppender.java:159)
    org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:230)
    org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:65)
    org.apache.log4j.Category.callAppenders(Category.java:203)
    org.apache.log4j.Category.forcedLog(Category.java:388)
    org.apache.log4j.Category.log(Category.java:853)
    org.apache.commons.logging.impl.Log4JLogger.debug(Log4JLogger.java:110)
    org.apache.struts.tiles.commands.TilesPreProcessor.getRequiredDispatcher(TilesPreProcessor.java:274)
    org.apache.struts.tiles.commands.TilesPreProcessor.doForward(TilesPreProcessor.java:257)
    org.apache.struts.tiles.commands.TilesPreProcessor.execute(TilesPreProcessor.java:217)
    org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
    org.apache.commons.chain.generic.LookupCommand.execute(LookupCommand.java:304)
    org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:190)
    org.apache.struts.chain.ComposableRequestProcessor.process(ComposableRequestProcessor.java:283)
    org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
    org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
    javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

Ik heb wat op internet gezocht maar niet zoveel gevonden. Het enige wat ik gevonden heb is dit:
http://threebit.net/mail-archive/tomcat-users/msg12038.html

I have had the same. The problem was not the redeploy, but the
un-deploy as part of the redeploy.
Can it be, that you have own threads running? At least it was my
problem, I had threads running, and dear mr. tomcat has already
deinitialized class loaders, so my classes lost their static variables
and a simple log.debug call ended in a null pointer.

Hier staat jammer genoeg geen oplossing bij...
Mijn applicatie is volgens de correcte specificaties ontwikkeld en ik heb zelf geen thread ergens in mijn code toegevoegd.

Om tomcat weer online te krijgen moet ik hem altijd herstarten waardoor ik de webapp van mijn collega ook plat leg. Op deze manier ontwikkelen is niet zo aangenaam.

Kan iemand mij wat op weg helpen om dit probleem op te lossen?

[JKVA]

Kun je je log4j.xml eens laten zien? Log4j lijkt de fout te veroorzaken...

[Janoz]

Dat je deze 500 error terug krijgt betekent niet dat tomcat gecrashed is. Deze foutmelding treed binnen je applicatie op. Voor fouten tijdens het (re)deploy proces zul je naar de serverlogs zelf moeten kijken en niet wat er in je browser verschijnt.

Als ik even snel nadenk en kijk naar de volgende punten:
(*)De fout treed op in de logging, niet rechtstreeks je eigen code
(*)Je upload met ftp
(*)Je gebruikt autodeploy

dan zou het heel misschien kunnen komen omdat de upload te lang duurt en dat tomcat al begint te deployen terwijl de upload nog niet helemaal binnen is. Dat probleem heb ik zelf wel eens gehad en is simpel op te lossen door eerst te uploaden en vervolgens op de server pas de war naar de autodeploy dir te kopieren. Maar of dit ook jouw probleem is weet ik niet.

Het lijkt me sowieso handig dat je de serverlogs eens gaat uitpluizen.

[JKVA]

Janoz schreef op donderdag 30 augustus 2007 @ 09:18:
--- knip ---
dan zou het heel misschien kunnen komen omdat de upload te lang duurt en dat tomcat al begint te deployen terwijl de upload nog niet helemaal binnen is. Dat probleem heb ik zelf wel eens gehad en is simpel op te lossen door eerst te uploaden en vervolgens op de server pas de war naar de autodeploy dir te kopieren. Maar of dit ook jouw probleem is weet ik niet.

--- knip ---

Idd, misschien is het een idee om een keer Tomcat te restarten, eventueel in combinatie met het leeggooien van de temp en work folders.

Je kunt ook in je Tomcat manager je context een keer met de hand reloaden, nadat je je WAR hebt neergezet.

[Johan.B]

Janoz schreef op donderdag 30 augustus 2007 @ 09:18:
Dat je deze 500 error terug krijgt betekent niet dat tomcat gecrashed is. Deze foutmelding treed binnen je applicatie op. Voor fouten tijdens het (re)deploy proces zul je naar de serverlogs zelf moeten kijken en niet wat er in je browser verschijnt.

Volgens mij zit het probleem niet alleen in mijn applicatie want de applicatie van mijn collega crashed mee wanneer ik redeploy...

De inhoud van mijn log4j:

Java:

# Set root logger level to ERROR and its only appender to webapp.
log4j.rootLogger=DEBUG, webapp

# webapp is set to be a DailyRollingFileAppender.
log4j.logger.webapp=DEBUG, webapp
log4j.appender.webapp=org.apache.log4j.DailyRollingFileAppender
log4j.appender.webapp.File=@logpath@/webapp.log
log4j.appender.webapp.DatePattern='.'dd-MM-yyyy
# webapp uses PatternLayout.
log4j.appender.webapp.layout=org.apache.log4j.PatternLayout
log4j.appender.webapp.layout.ConversionPattern=%d{DATE} [%-5p] %c {%F:%L} - %m%n

# extranet is set to be DailyRollingFileAppender
log4j.logger.be.groept.struts=INFO, extranet
log4j.logger.be.groept=DEBUG, extranet
log4j.appender.extranet=org.apache.log4j.DailyRollingFileAppender
log4j.appender.extranet.File=@logpath@/extranet.log
log4j.appender.extranet.DatePattern='.'dd-MM-yyyy
# extranet uses PatternLayout.
log4j.appender.extranet.layout=org.apache.log4j.PatternLayout
log4j.appender.extranet.layout.ConversionPattern=%d{DATE} [%-5p] %c {%F:%L} - %m%n

# request is set to be DailyRollingFileAppender
log4j.logger.request=INFO, request
log4j.appender.request=org.apache.log4j.DailyRollingFileAppender
log4j.appender.request.File=@logpath@/request.log
log4j.appender.request.DatePattern='.'dd-MM-yyyy
# request uses PatternLayout.
log4j.appender.request.layout=org.apache.log4j.PatternLayout
log4j.appender.request.layout.ConversionPattern=%d{DATE} %m%n

# licenties is set to be DailyRollingFileAppender
log4j.logger.licenties=INFO, licenties
log4j.appender.licenties=org.apache.log4j.DailyRollingFileAppender
log4j.appender.licenties.File=@logpath@/licenties.log
log4j.appender.licenties.DatePattern='.'dd-MM-yyyy
# licenties uses PatternLayout.
log4j.appender.licenties.layout=org.apache.log4j.PatternLayout
log4j.appender.licenties.layout.ConversionPattern=%d{DATE} %m%n

# yuri is set to be DailyRollingFileAppender
log4j.logger.yuri=INFO, yuri
log4j.appender.yuri=org.apache.log4j.DailyRollingFileAppender
log4j.appender.yuri.File=@logpath@/yuri.log
log4j.appender.yuri.DatePattern='.'dd-MM-yyyy
# yuri uses PatternLayout.
log4j.appender.yuri.layout=org.apache.log4j.PatternLayout
log4j.appender.yuri.layout.ConversionPattern=%d{DATE} %m%n

[Janoz]

Het kan best zijn dat jouw applicatie er voor zorgt dat de logger onderuit gaat en dat daardoor de applicatie van je collega het ook niet meer doet. Het punt is echter dat tomcat nog keurig foutpagina's via HTTP oplevert dus Tomcat zelf is niet gecrasht.

Blijft verder nog staan dat je, om het echte probleem te kunnen lokaliseren, niet naar de foutmeldingen in de browser moet kijken, maar in de logs van Tomcat.

[JKVA]

Misschien een classloading probleem? Package je zelf een log4j mee? Hoe zien de Tomcat logging bestanden eruit? Staat daar toevallig een andere log4j.xml?

[Salandur]

ik heb het probleem ook gehad. het bleek dat struts om de een of andere reden niet verwijderd kan worden uit de containter en blijft dus achter. vervolgens bij een deploy wordt de applicatie niet gedeployed omdat de map al bestaat
overigens was dat met tomcat 5.5 op windows, maar ik kan me voorstellen dat het probleem ook optreedt bij linux

[JKVA]

Salandur schreef op donderdag 30 augustus 2007 @ 18:21:
ik heb het probleem ook gehad. het bleek dat struts om de een of andere reden niet verwijderd kan worden uit de containter en blijft dus achter. vervolgens bij een deploy wordt de applicatie niet gedeployed omdat de map al bestaat
overigens was dat met tomcat 5.5 op windows, maar ik kan me voorstellen dat het probleem ook optreedt bij linux

En dan krijg je deze stack trace? Das wazig...

[Jorick]

Janoz schreef op donderdag 30 augustus 2007 @ 09:18:
...
dan zou het heel misschien kunnen komen omdat de upload te lang duurt en dat tomcat al begint te deployen terwijl de upload nog niet helemaal binnen is. Dat probleem heb ik zelf wel eens gehad en is simpel op te lossen door eerst te uploaden en vervolgens op de server pas de war naar de autodeploy dir te kopieren. Maar of dit ook jouw probleem is weet ik niet.
...

Ik heb zelf ook een problemen met Tomcat als ik een grote war (hangt samen met de uploadsnelheid) rechtstreeks naar de webapps deploy. Ik upload altijd eerst mijn .war naar een temp map en daarna move ik de war naar /webapps.

Zoals hier boven ook al aangegeven is kun je het beste even in /logs rondsnuffelen. Daar staat vaak veel nuttige informatie in ook al is het soms erg cryptisch . Ik vermoed dat het met je libs niet helemaal snor zit.

[Johan.B]

Het probleem is ondertussen opgelost: De lib die in de tomcat common dir stond had niet dezelfde versie nummer dan de lib die we gebruiken om te ontwikkelen.