Websphere JSP Seiten crashen Dominoserver

[Ralf_M_Petter]

Hallo Domino Freunde!

Ich habe folgendes Problem. Unsere Webseite läuft mittlerweile auf Websphere Express 5.1.1 auf einer Iseries. Die Daten der Webseite (Texte Bilder usw) liegen auf dem Domino Server 6.0.3 auf der selben Iseries. In den JSP wird über die Notes.jar mit der lokalen Zugriffsmethode auf die Dominodaten zugegriffen. Normalerweise läuft das einwandfrei. Ich arbeite auch wie empfohlen mit den richtigen Tricks um zu gewährleisten, dass auf jedes NotesThread.sinitThread() ein NotesThread.stermThread() kommt. Also sprich das NotesThread.stermThread() ist im finally des try catch Blocks der den Domino Code umschliesst. Aber ab und zu wenn ich den Websphere beende und neu starte, kommt es zu einer Hang Situation. Der Domino Server friert ein und reagiert auf keine Console Befehle mehr und auch der Websphere kann keine Zugriffe mehr machen. Man kann nur noch den Dominoserver mit endsbs domino00 *immed beenden. Dann beendet sich auch der Websphere Server. Danach gestaltet sich das starten der Server äussert schwierig. Der Domino startet zuerst einwandfrei und würde auch ohne Probleme laufen, jedoch sobald man den Websphere startet hängen Sie sich sofort, oder nach ein paar Sekunden in denen es funktioniert auf. Man muß dann ein paar mal probieren und plötzlich ohne erkennbaren Grund läuft es wieder.

Meine Vermutung ist, dass wenn man den Websphere beendet, kann es ab und zu passieren, dass Threads die momentan gerade zwischen NotesThread.sinitThread und dem dazugehörigen stermThread beendet werden. Ist das überhaupt möglich?

Die Zweite Frage Was passiert wirklich wenn ein sinitThread nicht abgeschlossen wird, und warum ist das nach dem Neustart des DominoServers und des Webservers nicht weg.

Wäre echt Spitze wenn da jemand was dazu sagen könnte.

Grüße

Ralf

[Ralf_M_Petter]

Habe natürlich parallel zum Posten hier weitergeforscht und bin auf folgendes gekommen. Ich habe in meine JSP's an verschiedenen Stellen die Ausgabe von Stacktraces eingebaut um weitere Informationen zu bekommen, wenn der Zugriff auf Domino aus irgendeinem Grund scheitert. dabe bekomme ich folgenden Stacktrace

java.lang.Exception: Error initializing Java environment storage
at java.lang.Throwable.<init>(Throwable.java:195)
at java.lang.Exception.<init>(Exception.java:41)
at lotus.domino.NotesThread.sinitThread(NotesThread.java:177)
at org.apache.jsp._einbaut._jspService(_einbaut.java:166)
at com.ibm.ws.webcontainer.jsp.runtime.HttpJspBase.service(HttpJspBase.java:89)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet$JspServletWrapper.service(JspServlet.java:396)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.serviceJspFile(JspServlet.java:852)
at com.ibm.ws.webcontainer.jsp.servlet.JspServlet.service(JspServlet.java:950)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.ibm.ws.webcontainer.servlet.StrictServletInstance.doService(StrictServletInstance.java:110)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet._service(StrictLifecycleServlet.java:174)
at com.ibm.ws.webcontainer.servlet.IdleServletState.service(StrictLifecycleServlet.java:313)
at com.ibm.ws.webcontainer.servlet.StrictLifecycleServlet.service(StrictLifecycleServlet.java:116)
at com.ibm.ws.webcontainer.servlet.ServletInstance.service(ServletInstance.java:283)
at com.ibm.ws.webcontainer.servlet.ValidServletReferenceState.dispatch(ValidServletReferenceState.java:42)
at com.ibm.ws.webcontainer.servlet.ServletInstanceReference.dispatch(ServletInstanceReference.java:40)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch(WebAppRequestDispatcher.java:1019)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch(WebAppRequestDispatcher.java:592)
at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward(WebAppRequestDispatcher.java:204)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward(WebAppInvoker.java:125)
at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook(WebAppInvoker.java:286)
at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation(CachedInvocation.java:71)
at com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invoke(CacheableInvocationContext.java:116)
at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI(ServletRequestProcessor.java:186)
at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service(OSEListener.java:334)
at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest(HttpConnection.java:56)
at com.ibm.ws.http.HttpConnection.readAndHandleRequest(HttpConnection.java:615)
at com.ibm.ws.http.HttpConnection.run(HttpConnection.java:449)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:912)


Aber die Freude, einer konkreten Fehlermeldung war zu früh, denn zu diesem Fehler bekomme ich in Google 0 Treffer auch in der Notes Knowledgebase konnte ich nichts finden. Kennt jemand vielleicht diesen Fehler. Würde mich über jede Hilfe freuen.

Grüße

Ralf

[Marinero Atlántico]

Frage: Warum verwendest du keine
a) Model 2 Architecture wie z.B. Struts (echt nicht so schwierig)
b) Domino Toolkit for Domino (oder so ähnlich --> Taglibs für Zugriff auf Domino.

Diese Zeile sieht für mich merkwürdig aus:

Code

at org.apache.jsp._einbaut._jspService(_einbaut.java:166)

Wie kommt das?

[Ralf_M_Petter]

Hallo Axel!

Das ist eine Webanwendung die schon sehr lange besteht und zu Zeiten entwickelt wurde, wo Struts und auch das Domino Toolkit for Domino noch nicht bestanden haben, bzw. noch in den Kinderschuhen gesteckt haben. Ein Umstellen der Bestandsapplikationen und auch unserer Datenbankzugriffsklassen auf ein neues System übersteigt momentan meine Ressourcen. Was kommt dir an der Zeile at org.apache.jsp._einbaut._jspService(_einbaut.java:166) komisch vor?

einbaut ist der Name der JSP Seite die gerade angezeigt wird. -einbaut.java ist vermutlich das servlet, dass der Websphere da draus generiert hat.

Mir geht es hauptsächlich um die Fehlermeldung "Error initializing Java environment storage" die offensichtlich die sinitThread() Methode von NotesThread wirft. Kann diese in Google nicht finden.

Grüße

Ralf

[Marinero Atlántico]

Ich kenn die Expressversionen nicht, aber ich meine, ich hätte bei Websphere nie irgendwelche apache Klassen gesehen. Sieht so aus, als ob er die JSP-Engine von Tomcat benutzen würde?

Noch ein Punkt (und ich bin ziemlich am Rätseln): Kann es vielleicht daran liegen, dass Websphere mehrere Servlet-Instanzen des aus diesem JSP generierten Servlet anlegt und damit irgendwie die lokalen Verbindungen zu Domino belegt werden?

Ansonsten würde ich es mal auf der Webseite von Bob Balaban versuchen.

Gruß Axel

[Ralf_M_Petter]

Hm!

Habe jetzt mal einen Stacktrace händisch in der Entwicklungsumgebung durchgeführt im Webspehere Express Testserver vom WSDC. Da schreibt er die Zeile auch mit Apache. Das seltsame ist, dass momentan läuft der Websphere und der Domino wieder einwandfrei. Meine Vermutung geht wie gesagt dahin, dass das Problem auftritt wenn man den Websphere neu startet, während Zugriffe auf die Servlets erfolgen. Ich befürchte er ruft dann während das Servlet gerade läuft die Destroy Methode auf. und erledigt dann den Thread. Das heisst, er unterbricht das Servlet zwischen der Grenze von NotesThread.sinitThread und NotesThread.stermThread.  Dadurch kommt Domino aus dem Tritt, da er extrem sensibel reagiert, wenn auf ein init kein term folgt. Eine Bestätigung dieses Sachverhalts wäre natürlich für mich extrem wertvoll, denn dann muß ich einfach schauen, dass ich zuerst den Zugriff auf die Servlets unterbinde und dann erst den Websphere stoppe. Habe übrigens jetzt ein Problem bei IBM dazu eröffnet und denen mal die ganzen Logs von unserem Websphere geschickt. Schauen wir mal was die dazu sagen.

Grüße

Ralf

[Marinero Atlántico]

Guter Punkt !!!

Es gibt in jsp wie du vermutlich weisst eine Destroy-Methode, die im Lifecycle immer unmittelbar vor dem zerstören der Servlet Instanz aufgerufen wird. Keine Zeit jetzt die Syntax abzuschecken. Aber da kannst du vielleicht dein stermThread zusätzlich reinschreiben?
Vermutlich nicht, weil NotesThread lokal in _jspService verwendet wird? Ach ne. Ist ja eine Klassen-Methode.

Gruß Axel

[Ralf_M_Petter]

An das hätte ich schon gedacht, aber leider geht das auch nicht, da Destroy ja vermutlich ein anderer Thread ist. Und vor allem es darf nie ein termThread gemacht werden ohne sinit. Dieses Dominospezifikum geht mir schon so auf die Nerven.

Ich warte jetzt erst mal ab, was die IBM sagt und berichte dann. Danke für deine Ideen. Hilft oft schon wenn man anderen Input kriegt um wieder etwas weiterzukommen auch wenn die Lösung noch nicht in Sicht ist.

Grüße

Ralf

[Marinero Atlántico]

Ich frage mich, ob du den sinitThread/stermThread Teil nicht in einen synchronized Block einschliessen musst?
Wie du weisst sind servlets multithreaded, d.h. as-is kann 2x hintereinander sinitThread aufgerufen werden. Was passiert dann?

Gruß Axel

[Ralf_M_Petter]

Das ist nicht weiter tragisch, da ja sinitThread immer nur für einen Thread gilt. Das heisst, wenn in einem Thread sinitThread kommt. Dann beim selben Servlet Thread2 mit sinitThread dann Thread1 mit stermThread terminiert wird  und dann Thread2 ebenfalls terminiert wird ist das kein Problem. Ein crash kommt wenn entweder in ein und dem selben Thread 2 mal der Thread initialisiert wird, oder wenn der Thread nicht terminiert wird. Ich habe aber keine Ahnung, bzw wäre ich froh wenn ich wüsste was beim Initialisieren bzw beim Terminieren passiert. Die von IBM haben in der Zwischenzeit geschrieben und zusätzliche Details wie releasestände Patches usw. angefordert. Aber sonst noch nichts neues. Ausser dass ich den Server wieder zum laufen bekommen habe ohne genau zu wissen warum und momentan läuft er. Wahrscheinlich bis zum nächsten mal, wo ich etwas an der Applikation updaten muß. Das ist spätestens nächste Woche der Fall.

Grüße

Ralf

[Marinero Atlántico]

Ralf,

ich bin mir zu 99.8% sicher, dass irgendwo in der Servlet-Spec 2.3 steht, dass bei einem stopp des Servers:
1. sämtliche service-Methoden Threads des Servlets (also doPost, doGet, etc, jspService (oder so ähnlich)) bis zu Ende ausgeführt werden
2. die destroy Methoden des Servlets aufgerufen werdne
3. die Servlets aus dem Speicher entfernt werden
4. der Server runterfährt.
Also, ein sehr geordneter Prozess.

Hilft natürlich nichts, wenn der Stecker rausgezogen wird, wobei IBM dieses Problem in WAS6 angehen will.

Du solltest aber auf jeden Fall den Teil:

Code

<%
NotesThread.sinitThread();
...
NotesThread.stermThread();

in einen try-catch einschliessen.

vielleicht hilfts ja

Axel

[Ralf_M_Petter]

Hallo Axel!

Was meinst du mit Punkt1 was wird da aufgerufen, oder meinst du er wartet bis alle Threads fertig sind?

Mein Code sieht folgendermassen aus. natürlich vereinfacht.
<%@ page import="lotus.domino.*" %>
<%
try {
NotesThread.sinitThread();
ses = NotesFactory.createSession();
// Tue jetzt was immer du willst mit der Session
}
catch (NotesException ne) {
ne.printStackTrace();
}
finally {
ses.recycle();
NotesThread.stermThread();
}

%>
// Hier kommt dann alles was Design ist.


Das einzige Risiko, dass ich noch sehe ist, dass wenn er bei der Anweisung wo er die Session erstellt einen Fehler macht ses eventuell null ist und er dann im finally ein Problem hat. Weisst du zufällig was passiert wenn im finally eine Exception geworfen wird, also z.B. bei ses.recycle();

Das rätselhafte ist, ja wenn er einmal läuft so wie jetzt und keine Fehlermeldungen kommen wie z.B. die MCH3601 im Joblog des Websphere Servers dann läuft er über Stunden auch unter Last. Probleme gibts nur beim beenden und starten, wenn man das War updaten will.

Grüße und danke für die Anregungen.

Grüße

Ralf

[Marinero Atlántico]

Die service() Methoden (also doPost, etc. s.o.) sind ja MultiThreaded, d.h. es wird pro Aufruf ein neuer Thread erzeugt.
Bsp.: Request1 von User hat zu einem neuen Thread des Servlets geführt. In diesem Thread wird die Methode org.apache.jsp._einbaut._jspService(_einbaut.java) durchgelaufen. Dort ist ja der meiste code des jsps.
Ich bin mir zu 99.8% sicher, dass bei einem "normalen" Beenden des Servers diese Methoden zu Ende bearbeitet werden. Der Server wartet solange mit dem Runterfahren.

Wenn in finally ein Fehler geworfen wird, wird das an den Aufrufer delegiert, d.h. der wirft die Exception und springt aus der Methode: normales Fehlerverhalten (es sei denn es wird gecached).
Du kannst ja mal versuchen im finally auf ses != null abzufragen. 

Gruß Axel

[Ralf_M_Petter]

Werde ich probieren, sind halt nur jede Menge JSP's aber sicher einen Versuch wert.

Grüße

Ralf

[Marinero Atlántico]

kann mir jetzt nicht die Bemerkung verkneifen, dass mit einem einigermassen sauberen Objektmodell und Model2 Schichtung dieses Problem wesentlich kleiner wäre. 

[Ralf_M_Petter]

Gebe dir ja recht, aber erstens ist man später immer klüger und zweitens verhindert die Dominoproplematik mit den Threads und mit recycle viele moderne Konstrukte. Den ich würde gerne mal sehen, wie lange eine moderne Applikation läuft, wenn man nicht dauernd manuell überall dahinter ist, dass auch die recycle() richtig laufen. Da muß sich Lotus dringend was einfallen lassen. Ich versteh ehrlichgesagt nicht ganz, warum Lotus nicht einmal ein paar Leute abstellt, die Java Backendklassen komplett auf Java umsetzt. So dass für die Kommunikation mit dem Server RPC verwendet wird. Dann wären alle Probleme auf einen Schlag weg und man könnte auch JavaObjekte über Sessiongrenze hinweg verwenden usw.

Grüße

Ralf

P.S. von IBM noch neues, ausser dass ich im Stundentakt Daten für die IBM bereitstellen darf.


Achtung ich bin erst am Donnerstag wieder in der Firma, da ich Krampusferien habe. Kann daher nur verzögert antworten.

[Marinero Atlántico]

Hi,

ein paar Vergleiche mit anderen Umgebungen:
-> wenn du aus JSP/Servlet auf ein RDBMS zugreifst wird die Connection auch innerhalb eines request-responce cycles neu geöffnet und geschlossen. Gleiches gilt natürlich auch für Transaktionen. Natürlich hat man für RDBMS Connections sowas wie Connection Pools (weniger Performance-Sorgen).
-> in SWT/JFace (GUI-Apis) von Eclipse gibt es etwas genau analoges wie recycle(). Heisst da nur dispose().

Ich glaub, dass man damit klarkommt. Bleiben natürlich das Performance Problem, dass man sich ständig neue NotesSessions besorgen muss.

Glaub aber - nach konkreten Nachdenken - dass die Spezialbedingungen für den Zugriff auf Domino (recycle() + seine Folgen) absolut nicht gegen eine "moderne Architektur" (= Model2) sondern eigentlich sehr dafür sprechen.
Dann kann man auch eher die Vorteile von Domino mit Websphere (statt mit z.B. Tomcat) ausspielen (Single Sign On).

Soweit ich wieder Zeit habe, kann ich mal eine einfache Struts Anwendung, die auf Domino zugreift durchcoden. Momentan habe ich leider total überhaupt keine Zeit.

Eine Anwendung von Model1 auf Model2 zu bringen dürfte natürlich einen ziemlich hohen Aufwand darstellen.
Gruß Axel

[Ralf_M_Petter]

Hallo Axel!

Das wäre sicher sehr interessant, aber wie gesagt, ich habe schon ein wenig in diese Richtung experimentiert und das Verhalten von Recycle ist wirklich der Horror. Denn es kann ab und zu passieren, dass wenn man ein untergeordnetes Objekt wie ein Notesentry recycelt, kann es passieren, dass man diesen Notesentry aus der NotesEntryCollection nicht mehr erstellen kann. Das heisst gewisse Objekte dürfen nur recycelt werden, wenn man sie sicher nicht mehr braucht. Da wird es dann schon höllisch.

Grüße

P.S. von IBM noch nichts neues, aber ich habe wieder ein paar Sachen herausgefunden, die ich dann gleich poste.

[Marinero Atlántico]

Hi Ralf,

ich sehe ein, dass das ohne konkreten Code Theorie-Waber ist.

Aber: Eclipse gilt ja als moderne Architektur. Und die dort verwendete Grafik-Library SWT lebt mit den gleichen Bedingungen.
Systemressourcen aus dem OS
- müssen explizit mit dispose() freigegegeben werden (Java Garbage Collection reicht nicht aus)
- der dispose() Befehl wird die Containment Hierarchie heruntergegeben. (analog zu notes: db.recycle() recycled auch alle views, die mit dem db Objekt erzeugt worden sind)
- Objekte, deren dispose() Methode aufgerufen worden ist, können nicht mehr wiederverwendet werden.

Glaub, dass mit sauberen geschichtete Architektur/OO-Design diese Bedingungen besser in den Griff zu kriegen sind.

Axel

[Ralf_M_Petter]

Falls du wirklich Zeit hast, sowas mal Testweise zu codieren, würde ich mich sehr freuen.

Zu meinem eigentliche Problem. Ich erhalte folgende Fehlermeldungen, während der Hang auftritt die mich in meiner Meinung bestätigen, dass das Problem auf jeden Fall beim initialisieren bzw terminieren der Threads auftritt.

Hier die Meldungen

MCH3601    Abbruch                 40   07.12.04  21:50:28,269024  LIBNOTES     QDOMINO603  *STMT    LIBNOTES    QDOMINO603  *STMT
                                     Von Benutzer  . . . . . . . :   QNOTES
                                     Ausgangsmosul . . . . . . . :   LOCAL
                                     Ausgangsprozedur  . . . . . :   OSLocalAllocNZ
                                     Anweisung . . . . . . . . . :   2
                                     Zielmodul . . . . . . . . . :   LOCAL
                                     Zielprozedur  . . . . . . . :   OSLocalAllocNZ
                                     Anweisung . . . . . . . . . :   2
                                     Thread  . . . . :   000000B3
                                     Nachricht . . . :   Zeiger für angegebene Position nicht gesetzt.
                                     Ursache  . . . . :  Es wurde ein Zeiger, entweder direkt oder als ein
                                       Basiszeiger verwendet, für den keine Adresse festgelegt worden war.
MCH3601    Abbruch                 40   07.12.04  21:50:28,469544  LIBNOTES     QDOMINO603  *STMT    LIBNOTES    QDOMINO603  *STMT
                                     Von Benutzer  . . . . . . . :   QNOTES
                                     Ausgangsmosul . . . . . . . :   LOCAL
                                     Ausgangsprozedur  . . . . . :   LocalTermThread
                                     Anweisung . . . . . . . . . :   1
                                     Zielmodul . . . . . . . . . :   LOCAL
                                     Zielprozedur  . . . . . . . :   LocalTermThread
                                     Anweisung . . . . . . . . . :   1
                                     Thread  . . . . :   000000B3
                                     Nachricht . . . :   Zeiger für angegebene Position nicht gesetzt.
                                     Ursache  . . . . :  Es wurde ein Zeiger, entweder direkt oder als ein
                                       Basiszeiger verwendet, für den keine Adresse festgelegt worden war.
MCH3601    Abbruch                 40   07.12.04  21:50:40,794504  LIBNOTES     QDOMINO603  *STMT    LIBNOTES    QDOMINO603  *STMT
                                     Von Benutzer  . . . . . . . :   QNOTES
                                     Ausgangsmosul . . . . . . . :   LOCAL
                                     Ausgangsprozedur  . . . . . :   OSLocalAllocNZ
                                     Anweisung . . . . . . . . . :   2
                                     Zielmodul . . . . . . . . . :   LOCAL
                                     Zielprozedur  . . . . . . . :   OSLocalAllocNZ
                                     Anweisung . . . . . . . . . :   2
                                     Thread  . . . . :   000000B3
                                     Nachricht . . . :   Zeiger für angegebene Position nicht gesetzt.
                                     Ursache  . . . . :  Es wurde ein Zeiger, entweder direkt oder als ein
                                       Basiszeiger verwendet, für den keine Adresse festgelegt worden war.
MCH3601    Abbruch                 40   07.12.04  21:50:40,808656  LIBNOTES     QDOMINO603  *STMT    LIBNOTES    QDOMINO603  *STMT
                                     Von Benutzer  . . . . . . . :   QNOTES
                                     Ausgangsmosul . . . . . . . :   LOCAL
                                     Ausgangsprozedur  . . . . . :   LocalTermThread
                                     Anweisung . . . . . . . . . :   1
                                     Zielmodul . . . . . . . . . :   LOCAL
                                     Zielprozedur  . . . . . . . :   LocalTermThread
                                     Anweisung . . . . . . . . . :   1

Falls diese Meldungen irgendwer kennt, oder weiß wo Informationen dazu stehen freue ich mich über die Info.

Grüße

Ralf