kopf.lastig » Java

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.

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.

JAMon 2.0 – Monitoring Java Applications

Administrator — Mon, 01 May 2006 21:45:02 +0000

Kürzlich wurde Version 2.0 von JAMon veröffentlicht. JAMon ist eine kleine, für Java-Anwendungen nützliche Monitoring-Bibliothek.

In Version 1 gab es die Möglichkeit, Ausführungszeiten von Code programmatisch zu messen:

PLAIN TEXT

JAVA:

Monitor m = MonitorFactory.start("berechnung");
BerechnungsModul.berechne();
m.stop();

misst die Ausführungszeit der berechne-Methode. Das interessante hierbei ist

Statistiken werden über die Ausführungszeiten (genauer: Ausführungsdauer) erstellt (Summe, Mittelwert, Standardabweichung und sogar Einteilung in bestimmte Klassen),
Ausführungszeiten werden Namen gegeben (hier "berechnung") und
Die Statistiken können als HTML-Report ausgegeben (programmatisch oder per JSP).

Damit ist schon viel getan, u.a.:

in Webanwendungen kann ich einen Servletfilter erstellen, der die Ausführungsdauer aller (oder nur bestimmter) Aufrufe misst (dies hat bei geringem Aufwand großen Nutzen),
Aufrufe an "externe Systeme" (z.B. Datenbank, Web-Services oder Betriebssystem) können gemessen werden
anhand der Messergebnisse kann der Entwickler abschätzen, ob eine Optimierung notwendig ist
anhand der Messergebnisse (z.B. im Vergleich zum Vortag) kann der Betrieb abschätzen, ob sich das System derzeit aussergewöhnlich verhält.

In Version 2 (ein komplettes Redesign) kommt hinzu, dass ich nicht nur Zeiten messen kann, sondern beliebige Einheiten. Ich kann z.B. eine Statistik über die Trefferzahl einer Suche führen:

PLAIN TEXT

JAVA:

int treffer = Suche.ausfuehren(...)
MonitorFactory.add("treffer","anzahl",treffer);

fügt die Trefferzahl dem Statistikeintrag "treffer", die in der Einheit "anzahl" gemessen wird, zu. Bisher habe ich nur noch nicht herausgefunden, wie man Klassen (im Sinne von "Unterteilung des Wertebereiches") für nutzerdefinierte Einheiten definieren kann.
Alles in allem ein Tool, welches einen großen Nutzen bringt. Das Spring-Framework unterstützt JAMon.

“Hibernate – A Developers Notebook” – migrating to Hibernate 3.0, Chapter 8

Administrator — Fri, 23 Dec 2005 22:31:20 +0000

Chapter 8 introduces Criteria Queries. Only QueryTest.java is affected. Besides the usual net.sf.hibernate to org.hibernate package import renaming, net.sf.hibernate.expressions in Hibernate 2 is replaced by org.hibernate.criterion.

Moreover, change the line

PLAIN TEXT

JAVA:

Example example = Example.create(new Artist(namePattern, null, null));

PLAIN TEXT

JAVA:

Artist artist = new Artist();
artist.setName(namePattern);
Example example = Example.create(artist);

because Hibernate 3 has generated no argument constructors only.

“Hibernate – A Developers Notebook” – migrating to Hibernate 3.0, Chapter 7

Administrator — Fri, 04 Nov 2005 18:26:20 +0000

Chapter 7 is working in Hibernate 3 (as opposed to chapter 6). The most challanging in this chapter migrationwise are StereoVolumeType.java and SourceMediaType.java . Change the import-package names. The Usertype-stuff is now under the package "org.hibernate.usertype". It won't compile, yet as there are some methods missing. For SourceMediaType.java:

PLAIN TEXT

JAVA:

public Object replace(Object original, Object target, Object owner)
throws HibernateException {
return original;
}
public Serializable disassemble(Object value) {
return (Serializable) deepCopy(value);
}
public Object assemble(Serializable cached,
Object owner)
{
// Our value type happens to be serializable, so we have an easy out.
return deepCopy(cached);
}
public int hashCode(Object o) { return o.hashCode(); }

For StereoVolumeType.java:

PLAIN TEXT

JAVA:

public Object replace(Object original, Object target,SessionImplementor session,
Object owner)
throws HibernateException {
return deepCopy((StereoVolumeType)original);
}
public int hashCode(Object o) { return o.hashCode(); }
public Object replace(Object original, Object target, Object owner)
throws HibernateException {
return original;
}

That's it.

“Hibernate – A Developers Notebook” – migrating to Hibernate 3.0, Chapter 6

Administrator — Mon, 26 Sep 2005 08:47:27 +0000

You can skip the entire chapter 6 if you use Hibernate 3. It is based on the interface PersistenceEnum which already became deprecated in Hibernate 2 as the author points out in the errata. The interface has apparently removed in Hibernate 3.

“Hibernate – A Developers Notebook” – migrating to Hibernate 3.0, Chapter 5

Administrator — Mon, 26 Sep 2005 08:44:37 +0000

As in chapter 4, copy the hbm.xml-files and change the DTD-reference. Leave CreateTest.java, QueryTest.java and QueryTest2.java alone - they will still compile. Copy the AlbumTest.java file, change the hibernate-imports and the constructor calls as well as int parameters to Integer.

This should be easy as we have done that before.

“Hibernate – A Developers Notebook” – migrating to Hibernate 3.0, Chapter 4

Administrator — Thu, 15 Sep 2005 15:26:12 +0000

In this chapter, we add an Entity called "Artist" as well as an entity called "Comments".

Copy both Track.hbm.xml and Artist.hbm.xml from the examples-distribution and remember to change the DTD-reference if necessary.
When using "ant schema", SAX complained it couldn't find ${src.root}/com/oreilly/hh/hibernate-mapping-2.0.dtd for Artist.hbm.xml.
That's strange because it didn't complain about it in Track.hbm.xml before. However, I place the DTD file in ${src.root}/com/oreilly/hh
and the prepare-target now copies *.dtd file, too.

The code generation is no problem. I has changed CreateTest.java again according to Java-beans coding style.
The package name in QueryTest.java and QueryTest2.java needs to be changed again from "net.sf.hibernate..." to "org.hibernate..." and everything works.

So that's it for chapter 4.

JSSE 1.0 bug keeps me busy

Administrator — Mon, 12 Sep 2005 16:16:50 +0000

An bug in JSSE 1.0.3 keeps me busy the whole monday - ending up with migrating from JDK1.2.2 to JDK1.4.2 "out of the cold".

In one of my maintenance project that realize some kind of an online-shop, "we" use a third-party website for payment. Last friday afternoon they installed a new SSL-certificate. Since then, the shop couldn't connect to that website with JSSE 1.0.3 (itself running an old setup with JDK1.2.2 and JRun - to be overhauled next month).

Tracing revealed "issuer != subject DN" - even for JDK1.4.2 . I couldn't figure out why. I tried to store the certificate in a keystore and cacerts but it wouldn't work either. So I tried a workaround using a dummy trust manager. It worked for JDK1.4.2 but not for JDK1.2.2.

In the end i figured out the server certificate had something like
O=#0C294A3...
in the subject which JSSE 1.0 cannot parse. So even without evaluating the certificate it didn't work. I was stuck here.

So we had no choice but to immediately upgrade to JDK1.4.2 since otherwise there was no payment possible. Luckily, it worked great! No problems so far!

If the thirdparty had noticed us about the new certificate, I had detected the problem as early as friday afternoon. But that's life I guess.