Archiv der Kategorie: Java

Java Heap-Dump erzwingen

Wer es mal brauchen sollte, einen Heap-Dump eines Java-Prozesses unter z. B. UBUNTU auf der Kommandozeile zu erhalten: Dazu muss ein Kernel-Parameter temporär auf ‚0‘ gesetzt werden. Als Tante ‚root‘ führt man folgendes aus:

‚echo „0“ > /proc/sys/kernel/yama/ptrace_scope‘.

Dann klappt auch unser Heap-Dump auf Kommandozeile:

‚jmap -F –dump:format=b,file=/tmp/XXXXXX.hprof <PID>‘

Ansonsten, wenn man nicht auf ein Terminal angewiesen ist, kann man z. B. die jconsole zu einem Heap-Dump veranlassen. Aber nicht vergessen, die Datei heißt so, wie der erste String-Parameter des Funktionsaufrufes. Das ist Default „String“ 🙂

jconsole_heapdump

Sucht man die PID laufender Java-Prozesse, kann man ‚jps‘ benutzen. Für Startparameter und anderes kommt ‚jinfo <PID>‘ zum Einsatz. Diese ‚unsupported‘ Tools sind im JDK enthalten.

ClassCastException with ElementNSImpl during unmarshalling

Dieser Fehler beim JAXB-Unmarshall brachte mich zu einem Fall einer XML-Annotation an einer Instanz-Variable generischem Typ:

@XmlElement(name=“begin“);
T begin;

Erst in einer Spezialisierung von der Basis-Klasse<T> wird ‚T‘ zu einem BigDecimal.

Erster Versuch war, Delegate-Getter an der Spezialisierung-Klasse anzubringen und entsprechend zu annotieren.

@XmlElement(name=“begin“, type=BigDecimal.class);
BigDecimal getBegin();

Das brachte noch nicht den Erfolg. Auch das Entfernen sämtlicher XML-Annotationen an unserer Basis-Klasse.

Erst, als in der Basis-Klasse der Member-Variablen ein neuer Name für die XML-Behandlung gegeben wurde, funktioniert es auch, zumindest für meinen Fall.

@XmlElement(name=“begin_intern“);
T begin;

Zum Prüfen ist es übrigens ziemlich hilfreich, sich die XSD erzeugen zu lassen.

JUGH: Lutz Huehnken, Von Enterprise zu Reactive

Reactive, was ist das eigentlich? Was bedeutet das für jemanden, der wie ich aus der J2EE-Business-Welt kommt?

Genau diesen Fragen ging Lutz Huehnken nach.
Er orientierte sich am Reactive Manifesto und übersetzte es in eine konkrete und am Entwickler orientierten Form: Kein Servlet-Container, kein blocking IO, Sub-Thread-Einheiten, kein Two-Phase-Commit.

DL1HX_jugh20151203_184723.1

Es hat mir sehr gut gefallen. Nicht einfach alles wegwerfen und auf neuen Paradigmen reiten. Sondern über die einzelnen Anforderungen nachdenken, nachdenken, ob ich überhaupt z. B. eine Transaktion so und an dieser Stelle benötige. Die Stellen zu isolieren, wo ich durch Zwänge nicht um blocking IO oder Two-Phase-Commit herumkomme.

Die Jugh-Vorträge erscheinen auch nach und nach auf Youtube, einfach mal danach suchen.

Gerade Events mit auch promienten Speakern, die Rede und Antwort stehen, gefallen mir immer besser … und ich nehme mir auch einfach die Zeit hierfür.

JUGH: Arno Haase: ‚Java Concurrency für Fortgeschrittene‘

Einer der besten Vorträge seit langem. Viel Bekanntes, welches aber von Arno in Zusammenhang gebracht ein neues Bild ergibt. Vorurteile und Annahmen beim alltäglichen Programmieren, bei denen sich herausstellt, dass sie einfach falsch bzw. veraltet sind. Was macht ‚volatile‘ wirklich, wie funktionieren die aktuellen Implementierungen von Collections oder Thread-Pools? Was ist das JAVA-Memory Model aktuell? Da werde ich mich wohl mal wieder hinsetzen müssen und neu lernen.

Besonders gut hat mir der ‚Satz von der Erhaltung des Elends‘ gefallen.

Den kenne ich als ‚Satz von der Erhaltung der Komplexität‘.

Danke Arno für die neuen Impulse

JUGH Link

Folien des Vortrags

iPhone dead => „Hallo World“@Android

CC BY 3.0
CC BY 3.0

Nach langer Zeit ist mein iPhone 3G gestorben. Will heißen, natürlich habe ich erst noch einmal den Akku ausgetauscht. Also das ganze Gerät auseinandergenommen, Akku eingesetzt, wieder verlustfrei geschlossen und nach 30 Minuten und winzigen Druckknöpfen und Verriegeln von mikroskopischen Foliensteckern festgestellt, dass die Ladeelektronik defekt ist.

iPhone dead => „Hallo World“@Android weiterlesen

HHH-1657

Aus Spaß trug ich mich in die Benachrichtigung eines sehr ärgerlichen und als ‚major‘ bezeichneten Fehlers bei Hibernate ein: HHH-1657.

Die Daten hierzu:

  • Created:
    Updated:
    Resolved:

In Worten zweitausendundsechs erzeugt. Die Krönung ist, er scheint trotz JIRA-Status nicht gefixed zu sein. Was soll man dazu noch sagen. Einfach die Kommentare lesen.

Cargo remote deployment Tomcat7: Error writing request body to server

I tried to deploy a WAR into a TomEE/Tomcat7 application server and I received an exception: „Error writing request body to server„. No Tomcat log file has useful information about that.

I use maven with Cargo plugin to deploy via the manager application of the Tomcat.

The configuration of the plugin inside the pom.xml is:

<plugin><!-- http://stackoverflow.com/questions/6436351/cannot-redeploy-to-remote-tomcat-7-with-using-cargo-maven-plugin, http://cargo.codehaus.org/Deploying+to+a+running+container -->
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.2</version>
<configuration>
<path>${remote.deployment.path}/${project.artifactId}/DEPLOY    /${project.artifactId}-DEPLOY.war</path>
<skip>${xxxx.deployment.skip}</skip>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.username>${xxxx.user}</cargo.remote.username>
<cargo.remote.password>${xxxx.pwd}</cargo.remote.password>
<cargo.remote.uri>http://${xxxx.host}:8080/manager/text</cargo.remote.uri>
</properties>
</configuration>
</configuration>
</plugin>

The command line is: mvn -X cargo:deployer-redeploy -P testsystem

In the internet I found two hints to solve the problem. First I checked the amount of bytes to send to the management application. There were some restrictions in the webapps/manager/WEB-INF/web.xml file at multipart-config>max-***-size.

Unfortunately this wasn’t my problem. The second hint were the proxy settings. I disabled my Ubuntu network proxy. But I forgot the ~/.m2/settings.xml of maven itself. After I fixed the maven proxy setting no exception occured and the deployment was successful.

 

TomEE: java.sql.SQLException: Unexpected token: NEXTVAL in statement [select nextval(‚SQ_TA_LOG_MASTER‘)]

Die Fehlermeldung – vom TomEE geworfen – „java.sql.SQLException: Unexpected token: NEXTVAL in statement [select nextval(‚SQ_TA_LOG_MASTER‘)]“ sagt nicht wirklich aus, was das Problem ist.
Es wird mit dem falschen SQL-Dialekt versucht, mit einer HSQL-DB zu sprechen, obwohl eine solche gar nicht im Projekt konfiguriert ist, zumindest nicht für den Kunden.

Nach dem wir endlich entdeckten, dass die tomee.xml Datei fehlte, wurde offensichtlich, dass die Applikation keine Datenbank vorfinden würde.
An dieser Stelle fühlt sich TomEE stillschweigend bemüßigt, seine Default-HSQL-DB zur Verfügung zu stellen.
Diese beschwert sich dann zu Recht, mit dem falschen Dialekt angesprochen zu werden.

Die Datasources richtig konfiguriert und alles klappt hervorragend.