Questions & Answers

Grayback · ‎08-14-2013

Hallo Leute,

Ich weiß nicht ob es genau hier hin gehört, aber man kann ja mal fragen.

Ich würde erstmal kurz unsere Komponenten und den Ablauf beschreiben und dann auf unser eigentliches Problem zu sprechen kommen.

Wir haben FirstSpirit 4.2.488 im Einsatz.

Unsere Webseiten hosten wir auf einem externen Server (Hoster: Host Europe).

Auf dem Server läuft ein Apache2, Tomcat6 und MySQL(in welcher Version weiß ich leider nicht).

Die Webseiten liegen auf einem anderen Server als unser FirstSpirit. Wenn ein Deployment gestartet wird, dann werden die Seiten

erst auf dem Server, wo auch FirstSpirit liegt generiert und dann mit der Hilfe eines RSyncs auf den Webseitenserver geschoben.

Von der Webseiten laufen täglich (nachts) Teildeployments, weil ein Volldeployment der Seite circa 16-18Stunden dauert. Deswegen wird jede Nacht ein Teildeployment gemacht, so das man am Ende der Woche ein Pseudo-Volldeployment gemacht hat.

Unser Hauptproblem ist, das der Webseitenserver circa alle 4Tage abschmiert. Somit die Webseiten auch nicht mehr erreichbar sind.

Um das Problem dann zu beheben muss der Tomcat und der Apache gestoppt werden, dann läuft jedoch immernoch ein Javaprozess, den ich dann killen muss. Danach starte ich Apache und Tomcat wieder und es läuft alles wieder.

Unsere Ideen dieses Problem zu beheben:

Flush-Hosts der MySQL Datenbank auf dem FirstSpirit Server -> ohne Erfolg
Manuelles Neustarten (später dann per Skript) des Servers aller 2Tage (somit eine kontrollierte Downtime zu haben) -> ohne Erfolg
Nagios (Monitoring) für den Server eingerichtet um zu erkennen ob es mit dem Deployments Nachts zusammenhängt -> tut es nicht, deshalb ohne Erfolg

Langsam gehen uns die Ideen aus. Deswegen frage ich mal hier. Vielleicht hat schon einmal jemand dasselbe oder ein ähnliches Problem gehabt.

Wenn ihr weitere Informationen braucht sagt Bescheid.

Ansonsten würde ich mich über jede Idee oder Lösungsvorschlag freuen.

Dankeschön

andre · ‎08-14-2013

> Webseitenserver circa alle 4Tage abschmiert.

also der Apache2 antwortet nicht mehr oder beim Tomcat liegt das Problem? ist der tomcat-manager erreichbar? also diese manager html console des tomcats?

> dann läuft jedoch immernoch ein Javaprozess, den ich dann killen muss.

man koennte schauen, ob mal mittels "jps" mehr infos ueber den java-prozess bekommt und/oder jstack [pid des java-prozesses]

ausserdem kann man probieren sich mittels jconsole auf den java-prozess zu verbinden um rauszubekommen welche java-vm das ist.

gibt es exceptions im log (firstspirit und tomcat) out of memory o.ä.?

> circa 16-18Stunden

und kein optimierungspotential?

Grayback · ‎08-14-2013

Hallo André,

Aus dem Stehgreif kann ich dir nichtmal sagen welcher das Problem verursacht. Ich müsste es Probieren wenn das nächste mal das Serverproblem eintritt.

Auf den Java-Prozess verbinden? Geht das? Ok ich hätte dazu sagen sollen das ich was Konsolenbefehle angeht Neuling bin.

Aber ich werde es mal probieren.

Im Firstspirit-Log gibt es keine Exceptions und im Tomcat auch nicht (wobei ich mir beim Tomcat grad nicht 100%ig sicher bin).

Und zu der langen Deploymentzeit, ja klar hätte das Optimierungspotenzial. Aber ist leider derzeit nicht geplant.

andre · ‎08-14-2013

Auf den Java-Prozess verbinden? Geht das? Ok ich hätte dazu sagen sollen das ich was Konsolenbefehle angeht Neuling bin.
Aber ich werde es mal probieren.

jconsole heisst das tool. sollte bereits installiert sein, sowohl unter linux als auch windows.

http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html

Grayback · ‎08-15-2013

Heute früh war es wieder soweit. Die Webseiten waren weg.

Leider mussten die Seiten schnell wieder da sein, so dass ich mich nicht auf den Javaprozess verbinden konnte.

Jedoch habe ich mir mal den Status vom Apache und Tomcat angeschaut und so wie es aussieht verursacht der Tomcat das Problem. Weil der Apache unter einer ganz anderen PID läuft als der Javaprozess, welcher sich immer aufhängt.

Dazu wäre noch anzumerken, der Javaprozess hat dann immer eine CPU-Auslastung von 150% (oder mehr).

Das letzte Mal war es Sonntagabend. Also wieder 4Tage zwischen den ausfällen. Ich werde Samstag den Server noch einmal kontrolliert neustarten in der Hoffnung das die Webseiten dann Montag nicht wieder weg sind.

feddersen · ‎08-15-2013

Nur zum Verständnis: Geht es um den Tomcat, der die Webseiten ausliefert oder geht es um einen Tomcat der die FirstSpirit Vorschau/Webedit etc. bereitstellt? Hört sich eher nach ersterem an.

Liefert der Tomcat vielleicht viele JSP-Seiten aus? Sind noch irgendwelche anderen Webanwendungen auf dem Tomcat aktiv? Die Logfiles des Tomcats sollten Hinweise liefern, was passiert.

Grayback · ‎08-15-2013

Ja es handelt sich um einen Tomcat, welcher die Webseiten ausliefert.

Naja das Projekt hat sehr viele Seiten, deswegen auch die Volldeploymentzeit von 16-18 Stunden.

Und es sind keine JSP-Seiten sondern wir haben Anfang des Jahres unsere kompletten Seiten auf JSF umgestellt.

Aus den Logs werde ich nicht schlau.

Der Ausfall fand 04:19Uhr statt.

Die einzigen Einträge im Log in dem Zeitraum sind einmal 03:25 und dann erst wieder 04:30.

Kein Eintrag zu der Zeit als die Webseiten ausfielen.

andre · ‎08-15-2013

> Dazu wäre noch anzumerken, der Javaprozess hat dann immer eine CPU-Auslastung von 150% (oder

mehr).

wenn das problem des tomcats auftritt, mal einen dump machen.

mittels jstack [java-process-pid]

statt der jconsole mal jvisualvm nutzen (wird auch mit dem jdk installiert) und unter threads schauen welcher die cpu-zeit verbraucht. auf dem threads-tab kann man auch einen threaddump machen.

mlieber · ‎08-28-2013

Hallo André, Christoph, Kenny,

heute war es bei uns wieder so weit.

Ich konnte dabei ein paar Logs mitschneiden und dazu habe ich auch noch einige Softwareversionen aufgeschrieben, in der Hoffnung, das hilft etwas weiter. Jeder Tipp wäre sehr hilfreich.

Tomcat 6.0.36
Oracle Java JDK 1.6.0.41_b02
libapache2-mod-jk 1.2.28-2
mysql-connector-java-5.1.23-bin.jar

Verwendete Klassen im Web-Projekt:
<firstspirit.version>4.2.488</firstspirit.version>
<firstspirit.version.prod>4.2.488</firstspirit.version.prod>
<guava.version>12.0</guava.version>
<jsf.version>1.2_15-B02</jsf.version>
<richfaces.version>3.3.3.Final</richfaces.version>
<seam.version>2.2.2.Final</seam.version>
<seam.servlet.path>/*</seam.servlet.path>
<myfaces.tomahawk.version>1.1.14</myfaces.tomahawk.version>
<mysql.version>5.1.21</mysql.version>
<junit.version>4.10</junit.version>
<testng.version>5.8</testng.version>
<jboss.embedded.version>beta3.SP10</jboss.embedded.version>
<javax.activation.version>1.1</javax.activation.version>
<slf4j.version>1.6.1</slf4j.version>
<javax.el.version>1.0</javax.el.version>

Folgendes erstes Log entstand einige Stunden vor dem Absturz. Könnte sein, dass sich Meldungen wie diese "aufstauen" und dann den Folge-Fehler verursachen:

Aug 23, 2013 6:03:54 AM org.apache.catalina.session.StandardSession expire

SEVERE: Session event listener threw exception

java.lang.IllegalStateException: Please end the HttpSession via org.jboss.seam.web.Session.instance().invalidate()

at org.jboss.seam.contexts.Lifecycle.endSession(Lifecycle.java:267)

at org.jboss.seam.contexts.ServletLifecycle.endSession(ServletLifecycle.java:187)

at org.jboss.seam.servlet.SeamListener.sessionDestroyed(SeamListener.java:59)

at org.apache.catalina.session.StandardSession.expire(StandardSession.java:720)

at org.apache.catalina.session.StandardSession.isValid(StandardSession.java:587)

at org.apache.catalina.connector.Request.doGetSession(Request.java:2406)

at org.apache.catalina.connector.Request.getSession(Request.java:2157)

at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:833)

at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:216)

at com.sun.faces.context.SessionMap.getSession(ExternalContextImpl.java:1006)

at com.sun.faces.context.SessionMap.get(ExternalContextImpl.java:961)

at org.jboss.seam.contexts.ServerConversationContext.get(ServerConversationContext.java:110)

at org.jboss.seam.Component.getInstance(Component.java:2002)

at org.jboss.seam.Component.getInstance(Component.java:1997)

at org.jboss.seam.Component.getInstance(Component.java:1970)

at org.jboss.seam.Component.getInstance(Component.java:1965)

at org.jboss.seam.core.Conversation.instance(Conversation.java:124)

at org.jboss.seam.faces.FacesManager.prepareBackswitch(FacesManager.java:260)

at org.jboss.seam.jsf.SeamPhaseListener.beforeRenderResponse(SeamPhaseListener.java:486)

at org.jboss.seam.jsf.SeamPhaseListener.beforeServletPhase(SeamPhaseListener.java:147)

at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:117)

at com.sun.faces.lifecycle.Phase.handleBeforePhase(Phase.java:214)

at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:96)

at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:374)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)

at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)