kopf.lastig » Softwarentwicklung

Einfache Konstruktoren

Administrator — Fri, 25 Sep 2009 11:52:04 +0000

Gespräch mit Kollege:
Gegeben Klasse A und Klasse B extends A und ich rufe im Konstruktor von A eine Methode auf, die in B überschrieben wird und die dort auf eine in B definierte Variable zugreift, dann ist diese Variable zum Zeitpunkt des Aufrufs nicht initialisiert. Das stimmt.

Wozu brauchst Du das?
Klasse Gruppenbaum, im Konstruktor lese ich Baum aus DB.
Na das ist ja nicht so gut. Konstruktoren sollten ihr Objekt in einen definierten Zustand bringen, mehr aber auch nicht. Wurde schon vor langer Zeit beschrieben.

Oracle Fehlermeldung: “Too many open cursors”

Administrator — Fri, 25 Sep 2009 11:47:36 +0000

Letztens haben wir nach Hardware- und JDBC-Treiber-Wechsel folgende Fehlermeldung bekommen:

ORA-01000: too many open cursors (oder auf deutsch: maximale anzahl offener cursor überschritten)

Tatsächlich gab es noch 2 Statements im Application-Server, bei das Statement nicht geschlossen wurde. Man findet die betreffenden Statements mit folgendem SQL:

PLAIN TEXT

SQL:

SELECT
c.sid,
c.address,
c.hash_value,
COUNT(*) AS "Cursor Copies"
FROM v$open_cursor c
GROUP BY
c.sid,
c.address,
c.hash_value
HAVING
count(*) > 2
ORDER BY
3 DESC

Unter Umständen kann man im Live-System beobachten, wie die Anzahl der offenen Cursor wächst.

Offensichtlich hat uns der vorherige JDBC-Treiber das nicht-Schliessen des Statements vergeben.

Finalizer in Java: lieber Finger weg!

Administrator — Fri, 19 Sep 2008 16:07:18 +0000

Laut Java-Spezifikation werden Finalizer in Java aufgerufen, bevor das entsprechende Objekt durch den Garbage Collector aus dem Speicher entfernt wird. Das klingt erst mal verlockend - hier könnte man ja automatische das Freigeben von Resourcen unterbringen.

Aber! Es wird nicht garantiert, wann der Finalizer aufgerufen wird. Die freizugebenden Resourcen sind solange blockiert. Schlimmer kommt es noch, wenn ein Finalizer ungewöhnlich lange für die Verarbeitung benötigt. Dann können die Resourcen, die die Objekte der anderen anstehenden Finalizer halten, nicht freigegeben werden. Dies kann zu Out-of-Filehandles oder zu Out-of-Memory-Fehlern führen, wenn die Entwickler sich auf die zeitnahe Abarbeitung von Finalizern verlassen.

Dies ist uns letztens passiert: Unsere Anwendung beendet sich nachweisbar nach einigen hundert Webservice-Aufrufen. Ergebnis der Problemanalyse: Ein Objekt einer Klasse des Oracle IAS scheint den Finalizer-Warteschlange zu blockieren, somit werden Objekte aus dem AXIS-(1.0)-Framework nicht finalisiert, die jedoch Referenzen auf speicherfressende DOM-Objektbäume halten. Diese DOM-Objektbäume können dadurch nicht garbage-collected werden, sammeln sich an und schliesslich kommt der Out-of-Memory-Fehler. Im generierten Webservice-Stub-Code haben wir manuell den Aufruf an den Finalizer (genauer: an die dispose-Methode) eingefügt und siehe da, dass Problem ist beseitigt.

An einer anderen Stelle (ebenfalls AXIS) sind wir vor 1-2 Jahren in ein ähnliches Problem gelaufen, da ging es jedoch um FileHandles oder Netzwerk-Ports. Auch da half manuelles freigeben der Resourcen.

Fazit: Es ist besser, die Resourcen von Hand freizugeben. "Zur Sicherheit" mag man noch einen Finalizer schreiben, aber wenn dieser wiederum die Finalize-Warteschlange blockieren könnte (etwa weil auf ein Netzwerk-Timeout gewartet wird), dann sollte man auch davon die Finger lassen.

Tools zum Analysieren von Memory-Dumps:

Troubleshooting – J2EE und Filesystem voll

Administrator — Fri, 08 Dec 2006 16:31:16 +0000

Wir hatten folgendes Problem.

Symptom: Manchmal wurden Bilder nicht geladen, Manchmal gab es Fehlermeldungen am Anfang oder Ende einer Seite.

Umgebung: J2EE-Anwendung auf Oracle IAS 9.0.4 (2 OC4J-instanzen) unter Sun Java VM 1.4.2 auf HP-UX, 8 Prozessor-Maschine, als Entwicklungsumgebung.

Analyse:

vmstat sagt: ca. 35-40 Prozesse laufen ständig, Anteil user 15%, Anteil sys 85%, idle 0%. Memory ist nicht knapp, Paging kaum
top sagt: eine oc4j-Instanz verursacht die prozessorlast
die log-files sind leer! (0 bytes)
jvm-stacktrace ergibt keine weiteren auffälligkeiten (kein anwendungscode im stacktrace, mostly waits oder Input/outputs)

Wir spielen das vorletzte build ein, welches am tag zuvor noch gelaufen ist.

Analyse:

redeploy sehr langsam
symptom und analyseergebnisse bleiben gleich

Wir rufen beim betrieb an.

Ergebnis: Filesystem voll!

nachdem der betrieb das problem behoben hatte, lief die anwendung (nach dem redeploy der aktuellen version) wieder normal.

How a firewall can break your app

Administrator — Fri, 03 Mar 2006 10:45:25 +0000

Picture this: after we had moved an old app from an old server to a new one, we kept getting "I/O Exception: Broken Pipe" now and then from our database connections. In the new environment, database lives on a different server than our app (as opposed to the old environment). Is there something wrong with the network?

My suspects turned out right: it's the firewall between app and database. It drops "unused" tcp connections after an hour. For some security reasons, this cannot be changed.

As our apps is rather old, some parts of it still do not use a connection pool and so there are db connnections that "linger" around unused for an hour and are used thereafter - bang, I/O exception.

So watch out for that and use a connection pool. Possibly one that can shrink (i.e. throw away unused connections).