Monthly Archives: September 2008

ThreadLocal Memory Leak

30. September 2008 von Mirko Novakovic

Da ich schon häufiger auf Memory Leaks gestoßen bin, die durch ThreadLocal Variablen auftreten, möchte ich dieses Phänomen genauer beleuchten.

ThreadLocal Variablen werden in Java benutzt, um Variablen an einen Thread zu binden – jeder Thread bekommt eine eigene, unabhängige Instanz dieser Variable zugewiesen. Normalerweise werden diese Variablen genutzt, um Status Informationen innerhalb eines Threads zu halten – z.B. die Benutzerkennung oder einen Mandanten.

Der Lebenszyklus einer ThreadLocal Instanz ist eng gekoppelt an den Lebenszyklus des entsprechenden Threads. Wird der Thread beendet und durch den GarbageCollector entfernt, sind auch die damit assoziierten ThreadLocal Variablen Kandidaten für den GarbageCollector.

Die Memory Probleme treten dann auf, wenn ThreadLocal Variablen innerhalb eines Application Servers verwendet werden. Application Server verwalten Thread in eigenen Thread Pools, um Ressourcen einzusparen und die Performance zu optimieren (Beispiel der Einstellungen für Tomcat 6 Http Conncector). Wird z.B. ein HttpServletRequest an die ServletEngine des Application Servers gesendet, wird für die Abarbeitung des Servlets ein freier, so genannten Worker-Thread aus dem entsprechenden Servlet ThreadPool entnommen. Dieser Thread arbeitet dann die Programmlogik des Servlets ab. Wird im Servlet oder der aus dem Servlet aufgerufenen Java Klassen eine ThreadLocal Variable genutzt, werden diese mit dem aktuellen Thread assoziiert. Nachdem das Servlet vom Thread abgearbeitet und die Response geschrieben wurde, wird der Thread aber nicht beendet und vom Garbage Collector aufgeräumt, sondern wieder in den ThreadPool zurückgegeben, so dass mit dem selben Thread einen neue Anfrage abgearbeitet werden kann. Die ThreadLocal Variablen bleiben also erhalten.

Je nach Größe des ThreadPools (in produktiven Systemen können das mehrere Hundert Threads sein) und der Größe der Objekte in der ThreadLocal Variable, kann das zu Problemen führen. Sind beispielsweise 200 Threads im ThreadPool aktiv und die ThreadLocal Varibale ist 5MB groß, belegen diese Variablen im schlimmsten Fall bereits 1GB Heap Speicher. Dies führt schnell zu erhöhter GC Aktivität und je nach Heap Größe zu einem Abbruch der JVM.

In einem konkreten Fall musste ein Server täglich neu gestartet werden, weil es zu einem OutOfMemoryError gekommen ist. Um das Prolem zu analysieren wurde zur Laufzeit ein Heapdump erzeugt. (siehe dazu den Blog Eintrag zur Erzeugung von Heapdumps) Die Analyse des Dumps mit Eclipse MAT hat ziemlich schnell gezeigt, dass es sich um ein ThreadLocal Problem handelt.

Der obige Screenshot zeigt den Dominator Tree des Dumps. Markiert sind 6 Threads die jeweils ca. 14MB Speicher referenzieren.

Der nächste Screenshot zeigt die Details eines Threads. Der hohe Speicherverbrauch ist auf eine ThreadLocal Variable zurückzuführen, die eine DOMParser inkl. geparstem Dokument referenziert – insgesamt mehr als 14MB groß. Da MAT auch die Inhalte der Objekte anzeigt, konnte an Hand des XML Inhalts identifiziert werden, dass die Dokumente zu einem WebService Aufruf gehören. Die Zugriffsklassen wurden mit JBoss WS generiert. Eine Suche in Google führte schnell zu einem Bug in der eingesetzten jbossws Version 1.2.0, der in der Version 1.2.1 gefixt wurde: “DOMUtils doesn’t clear thread locals”.

Das Beispiel zeigt, dass man vorsichtig sein muss, wenn man ThreadLocal Variablen innerhalb eines ApplicationServer verwendet (vor allem wenn man Application Server Hersteller ist). Es ist wichtig dafür zu sorgen, dass der Inhalt der Variablen gelöscht wird, bevor der Thread wieder in den ThreadPool zurückgestellt wird. Die Daten sind auch fachlich gefährlich, wenn Sie nicht gelöscht werden, da nicht vorhergesagt werden kann, welche Anfrage der Thread als nächstes bearbeitet.

In einigen Projekten in denen wir ThreadLocal Variablen nutzen, haben wir einen ServletFilter geschrieben, der dafür sorgt, dass die Daten bereinigt werden.

Kategorie: Performance | 0 Kommentare
Geschrieben am 30. September 2008 von Mirko Novakovic.

ScrumMaster Certification Training

30. September 2008 von Mirko Novakovic

Für unsere internen Projekte und bei einigen Kunden setzen wir seit einiger Zeit auf die agile Methode Scrum. Um unser Wissen zu vertiefen haben wir deshalb letzte Woche mit 13 codecentricern und 2 Kollegen unseres Kunden OEV Online das ScumMaster Certification Training bei Xebia in Holland absolviert. Das Training wurde von Jeff Sutherland durchgeführt, einem der Erfinder von Scrum. Die Folien zum Kurs kann man auf Jeffs Webseiten frei herunterladen.

Das Training war mit Sicherheit eines der Besten, an dem ich teilgenommen haben. Jeff ist ein hervorragender Trainer und Erzähler und seine Ansichten und Methoden um Software Projekte erfolgreich durchzuführen sind durch geniale Einfachheit geprägt und basieren im Prinzip auf einer Reihe erprobter Best Practises, die in Scrum zusammengefasst wurden.

Es gibt schon genügend Bücher und Artikel zum Thema Scrum, so dass dieser Blog Eintrag nur die Highlights und Erkenntnisse aus dem Kurs zusammenfassen soll.

Was ist Scrum?

Scrum ist kein Entwicklungsprozess, sondern eine Methode um Projekte jeglicher Art zu organisieren. Jeff plant beispielsweise die Wochenende zusammen mit seiner Frau auf einem ScrumBoard. Beispiele von anderen Personen, die Ihre Wochenendplanung mit Scrum organisieren, finden sich auch bei Flickr. Bei codecentric nutzen wir Scrum neben den Software Projekten auch um unsere Marketing und Vertriebsaufgaben zu organisieren – dabei setzen wir auf kurze 2 Wochen Sprints. Die Produktivität und Transparenz ist dadurch stark verbessert worden. Ich werde mir auch ein ScrumBoard im Büro aufhängen, um meine eigenen Aufgaben zu strukturieren. Jeff empfiehlt für Software Projekte den Einsatz von Scrum zusammen mit eXtreme Programming, um einen agilen Entwicklungsprozess in Scrum einzuführen. Insbesondere die XP Praktiken wie Continuous Integration, Test-Driven-Development und Coding Standards werden von Jeff als Ergänzung zu Scrum empfohlen. Wir setzen intern und beim Kunden extensiv auf diese Praktiken und der bisherige Erfolg bestätigt uns diesen Weg weiter zu gehen.

Der Nokia Test

Laut Jeff denken viele Teams, dass Sie Scrum einsetzen, machen es aber in Wirklichkeit nicht. Es ist sehr wichtig, dass man Scrum im Ganzen einsetzte und nicht nur einzelne Best-Practises, um die “Lämpchen leuchten zu sehen”, wie es Jeff formuliert. Als Beispiel hierfür nannte er Nokia, die Scrum in weiten Teilen des Unternehmens eingeführt haben. Um zu testen, ob Scrum auch richtig verwendet wird, entwickelte er den so genannten “Nokia Test”. Der Test besteht aus 8 Fragen, die die Teammitglieder der Scrum Team beantworten müssen. Je nach Antwort können 1-10 Punkte je Frage erreicht werden. Nur wenn die durchschnittliche Punktzahl pro Frage > 6 ist, macht ein Team wirklich Scrum und kann eine entsprechende Produktivität erreichen. Für mich hat dieser Test gezeigt, dass man hart daran arbeiten muss wirklich Scrum in seinen Teams einzuführen und wir führen den Test gerade in unseren Teams durch, um Verbesserungspotentiale zu finden.

Velocity

Scrum misst die Produktivität des Teams in jedem Sprint in Form der so genannten Velocity. Während des Kurses wurde mir erst richtig bewusst, wie groß der Nutzen dieser Metrik ist. Die Velocity gibt an, wie viele Story Points ein Team oder ein Teammitglied in einem Sprint abgeschlossen hat. Nach wenigen Sprints sollte die Velocity eines Teams relativ konstant sein, so dass man eine hervorragende Planungsgrundlage hat. Wichtig ist, dass man eine Velocity findet, die das Team nicht überfordert – man spricht deshalb von einer “sustainable pace”. Die Velocity kann aber auch zu Konflikten führen, da sehr schnell aufgezeigt wird, wenn einzelnen Teammitglieder oder Teams keine Velocity haben und damit unproduktiv sind. Transparenz kann eben manchmal auch weh tun. Interessant war auch der Vergleich der Produktivität von großen Scrum Projekten und Projekten die das Wasserfallmodell anwenden. Auf Basis einer längeren Studie konnte eine mehr als 7x (!) höhere Produktivität bei den Scrum Projekten nachgewiesen werden. Nicht umsonst setzen also Firmen wie Google, MySpace und Yahoo! auf Scrum und erzielen damit laut Jeff hohe Produktivitätsgewinne.

Emergency Procedure

Jeff war Jet-Pilot bei der U.S. Air Force, weshalb er besonderen Wert auf eine Emergency Procedure legt, um nicht als “smoking hole in the ground” zu enden. Merkt man in einem Sprint, das man die Ziele nicht erreichen wird, sollte man diese Prozedur anwenden. Wichtig ist dies frühzeitig zu machen, also maximal zur Halbzeit eines Sprints, weil man ansonsten nicht mehr “aussteigen” kann. Die empfohlene Prozedur von Jeff lautet:

Mache etwas anders.
Hole Dir Unterstützung.
Mache weniger.
Stoppe den Sprint.

Der erste Schritt sollte also immer sein nach Wegen zu suchen die Aufgaben anders anzugehen. Laut Jeff gibt es immer mehrer Wege ein Ziel zu erreichen und möglicherweise befindet man sich auf dem falschen und längeren Weg. Der zweite Schritt ist einen externen Experten temporär ins Team zu holen, um die Velocity zu erhöhen. Der dritte Schritt ist Inhalte aus dem Sprint Backlog zu streichen, um doch noch eine lauffähige Software fertigstellen zu können, die “business value” liefert. Bringen Schritte 1-3 nicht den gewünschten Effekt, muss der Spring gestoppt werden – besser man plant den Sprint neu, als das man als “Erdloch” endet…

Money for Nothing – Change for Free

Angelehnt an den Dire Straits Songs Money for nothing, schlägt Jeff einen neuen Ansatz für Festpreisprojekte vor: Money for Nothing – Change for Free. Grundlegend bedeutet das, dass man sich mit einem Kunden darauf einigt, dass das Projekt vorher beendet werden kann, wenn der Kunden mit den implementierten Funktionen zufrieden ist. Laut Jeff liefert meistens schon wenig Funktionalität sehr viel Business Value und der Kunde spart viel Geld, wenn er nicht das ganze Projekt umsetzen muss. Vom eingesparten Betrag erhält der Dienstleister einen vereinbarten Anteil, weil er ja nun nicht mehr das gesamte Projekt umsetzen wird. Man erhält aus quasi “Money for Nothing” und beide Seiten haben gewonnen – die klassischen Win-Win Situation. “Change for Free” bedeutet, dass der Kunde Anforderungen jederzeit ändern kann, indem er geplante Anforderungen durch Neue mit gleichwertigem Aufwand tauscht oder in der Priorisierung ändert. Da sich laut Jeff mindestens 60% der Anforderungen während eines Projekts ändern, ist dies die einzige Möglichkeit eine hohe Kundenzufriedenheit zu erreichen. Change Management ist aus seiner Sicht nur ein Prozess um dem Kunden nicht das zu geben, was er eigentlich haben möchte – für mich eine interessante Meinung, die ein Umdenken bei uns erfordert.

Skalierbarkeit und verteilte Teams

Sehr interessant waren auch die Beispiele bezüglich verteilter und großer Team in Verbindung mit Scrum. Prinzipiell würde man meinen, dass Scrum nur für kleine und lokale Teams geeignet ist. Jeff hat dies eindrucksvoll an Hand von einigen Beispiele wiederlegt. Scrum skaliert sehr gut und man nutzt dafür virtuelle Teams und so genannter Scrum of Scrums. Bei verteilten Teams kann man Distributed Scrum einsetzen, ein Verfahren bei dem das Team zunächst in einem Sprint zusammen und danach in getrennten Lokationen arbeitet. Eine Verteilung der Teams im Verhältnis 50:50 ist so ohne Verlust der Produktivität möglich. Xebia arbeitet so erfolgreich in großen Projekten mit Ihrer indischen Niederlassung zusammen und hat dies auch durch zahlreiche Statistiken belegt. Xebia hat dabei aber nicht nur die konstante Produktivität, sondern auch eine konstante Qualität nachgewiesen. Für uns ist das ein Beweis dafür, dass wir auf dem richtigen Weg sind. Ende Oktober startet unsere Niederlassung in Doboj, Bosnien und Herzegowina, in der wir Nearshoring Projekte auf Basis von Distributed Scrum durchführen werden.

Neben dem hervorragenden Inhalt war auch die Lokation an einem holländischen Kanal sehr gut gewählt, so dass wir in den Pausen in schöner Atmosphäre weiter diskutieren konnten.

Wir und unsere Kunden sind auf jeden Fall auch im November bei Jeffs Kurs dabei und zertifizieren einige Kollegen die dieses mal nicht teilnehmen konnten.

Kategorie: Agilität | 1 Kommentar
Geschrieben am 30. September 2008 von Mirko Novakovic.

Tomcat 6 Vortrag von Peter Roßbach bei der RheinJUG

26. September 2008 von Fabian Lange

Donnerstag hat Peter Roßbach, Entwickler im Tomcat Projekt, auf der RheinJUG in Düsseldorf einen Vortrag gehalten. Dabei handelte es sich nicht um einen langweiligen trockenen technischen Talk, sondern um ein lockeres Potpourri aus Tomcat Architektur, Best Practices, Open Source Community sowie aktueller und zukünftiger Entwicklung.

Performanceoptimierung im Tomcat

Zum Thema Performance nannte er als wesentlichen negativen Faktor die Benutzung des Entwicklungsmodus für Produktion. Im folgenden einige weitere Parameter die er mit ihrer Auswirkung auf die Performance beschrieb.

So gibt es im Tomcat 6 eine Verbesserte Protokollimplementierung:

außerdem ermöglicht Java NIO eine bessere Dateidownload Option. Servlets sollten dafür nur die Sendfile Request Parameter setzen und keine weiteren Daten ausgeben:

 org.apache.tomcat.sendfile.filename: Canonical filename of the file which will be sent as a String
 org.apache.tomcat.sendfile.start: Start offset as a Long
 org.apache.tomcat.sendfile.end: End offset as a Long

Produktionsserver sollten vor allem nicht automatisch deployen:

Der Jasper JSP Compiler sollte ebenfalls getuned werden:

  jsp
  org.apache.jasper.servlet.JspServlet
 
development
false
 
genStringAsCharArray
true
 
trimSpaces
true

mod_jk zum Loadbalancing

Als zweiten Schwerpunkt stellte er das Modul “mod_jk” vor, welches in Verbindung mit einem Apache Httpd und dem Tomcat AJP Protokoll dafür sorgt, daß Java Webapplikationen sich sinnvoll auf Tomcat Server verteilen lassen.

Er erläuterte die verschiedenen Loadbalancing Konfigurationen und daß es durchaus sinnvoll sein kann einen Tomcat Server pro Applikation zu verwenden. Dies begründet er insbesondere mit Memory Management und Ausfallsicherheit.

Tomcat Konfiguration:

mod_jk Konfiguration im Httpd:

  LoadModule jk_module "modules/mod_jk.so"
 
JkShmFile "logs/mod_jk.shm"
 
JKWorkerProperty worker.list=loadbalancer
JKWorkerProperty worker.node01.port=8009
JKWorkerProperty worker.node01.host=localhost
JKWorkerProperty worker.node01.type=ajp13
JKWorkerProperty worker.loadbalancer.type=lb
JKWorkerProperty worker.loadbalancer.connection_pool_minsize=0
JKWorkerProperty worker.loadbalancer.connect_timeout=30000
JKWorkerProperty worker.loadbalancer.prepost_timeout=10000
JKWorkerProperty worker.loadbalancer.balance_workers=node01
JKWorkerProperty worker.loadbalancer.method=Request
JKWorkerProperty worker.loadbalancer.retries=2
JKWorkerProperty worker.loadbalancer.recovery_options=7
JKMount /myapps* loadbalancer

Weitere Dokumentation zum mod_jk worker findet sich hier:

http://tomcat.apache.org/connectors-doc/reference/workers.html

Insgesamt ein recht unterhaltsamer Vortrag, aus dem man einiges lernen konnte über das Tomcat Projekt und die Tomcat Architektur, wie Open Source “lebt” und was man als Entwickler/Architekt einer Java Webanwendung so alles beachten sollte.

Kategorie: Performance, Web | 0 Kommentare
Geschrieben am 26. September 2008 von Fabian Lange.

Sommer Event 2008 – Center Parcs Port Zelande

11. September 2008 von Dragana Novakovic

Letztes Wochenende sind wir in den Center Parcs Port Zelande gefahren. Das war unser erstes Firmenevent am Meer. Nicht nur das codecentric Team, sondern auch deren Partner und Kinder waren dabei.

Am Freitagabend hatten wir wenig Glück mit dem Wetter, was der guten Party Stimmung aber nicht schaden konnte. Der Kampf mit der elektrischen Zapfanlage wurde gewonnen und das Feuer im Grill glühte bis in die frühen Morgenstunden.

Am zweiten Tag mussten wir dann alle wieder etwas arbeiten. Eine 10 km GPS-Tour war angesagt. Aufgeteilt in vier Gruppen und unterstützt durch sonniges Wetter, die wunderschönen Strände der Nordsee und die Herbstluft, gingen wir durch das Naturschutzgebiet der Halbinsel. Nach ein paar Stunden kamen wir alle mehr oder weniger erschöpft am Grill zusammen, wo wir wieder bis spät in die Nacht getanzt und getrunken haben.

Kölsch, Feuer, Musik und eine Menge gut gelaunter Freunde waren an diesem Wochenende auf dem kleinen Strand von Port Zelande zu sehen – sicherlich nicht das letzte Mal.

[Show as slideshow]

12 3 ►

Kategorie: Allgemein | 1 Kommentar
Geschrieben am 11. September 2008 von Dragana Novakovic.

Progress Software präsentiert Actional und DataXtend SI beim Freitagsmeeting

3. September 2008 von Andreas Ebbert-Karroum

Jeden letzten Freitag im Monat veranstaltet codecentric ein Freitagsmeeting. Im Rahmen der 20%-Weiterbildungszeit ist das eine gute Möglichkeit für alle Mitarbeiter sich gegenseitig über neue Technologien, Produkte oder andere interessante Dinge auszutauschen. Auch Firmen werden von uns zu diesem Meeting eingeladen, um uns ihre neuesten Produkte präsentieren zu können.

Letzten Freitag hatten wir Progress Software zu Gast; eine Firma die im Allgemeinen weniger durch Ihren Firmennamen als vielmehr durch Ihre Produkte bekannt ist, wie zum Beispiel dem Java Messaging / Enterprise Service Bus “Sonic MQ/ESB” oder den JDBC/ODBC Treiber “DataDirect“. Vor kurzem war Progress auch wegen der Akquisition von IONA und Mindreef in den Nachrichten. Mit den neuen Firmen ergänzt Progress das breite SOA Produktportfolio, aus dem uns Eric Schaumlöffel die beiden Produkte “Actional” und “DataXtend SI” vorstellte.

Progress Actional

Progress Actional stellt in einer SOA Überwachungs- und Sicherheitsfunktionen zur Laufzeit bereit und bietet darüber hinaus die Möglichkeit, nach Bedarf aktiv in den Message Flow einzugreifen. Dazu instrumentiert Actional die einzelnen teilnehmenden Services bei geringem Runtime-Overhead sowohl auf Anwendungsebene (App-Server) als auch im Protokoll-Stack (HTTP/S, IIOP, RMI, JMS, TCP).

Ohne weitere Konfiguration kann man in der Umgebung der instrumentierten Server die Auslastung und Richtung der Kommunikationspfade erkennen. Konfiguriert man Actional so, dass es weiß wo in den Nachrichten bestimmte Parameter zu finden sind, können Nachrichten mit einem eindeutigen Tracer markiert werden, sodass der Zusammenhang zwischen eingehenden und ausgehenden Nachrichten auch bei unterschiedlichen Protokollen hergestellt und diese einem übergeordnetem Geschäftsablauf zugeordnet werden können. Der globale Geschäftsprozess kann mit der Actional UI bis auf Methodenebene herunteranalysiert werden. Zusätzlich können durch die Nachrichtenmarkierung auch Policies erzwungen werden, sodass z.B. nur bestimmte Systeme miteinander kommunizieren dürfen.

Tendenziell kann man festhalten, dass Actional auf SOA Ebene das bietet, was dynaTrace mit der PurePath Technologie für Java und .NET Anwendungen bereitstellt, wobei es in den Anwendungsfällen sicherlich zwischen den beiden Produkten Überschneidungen gibt. Es mag vielleicht etwas befremdlich anmuten, dass man mit einem Produkt zum Monitoring auch Sicherheitsaspekte implementieren soll, wenn man die Sichtweise aber umdreht mach das Ganze Sinn: Vielmehr ist es so, dass Actional als Runtime SOA Governance Produkt konzipiert und positioniert ist, und alle technischen Notwendigkeiten, die für die Implementierung der sicherheitsrelevanten Funktionen vorhanden sind, sich als “Nebenprodukt” auch zum reinen Monitoring einsetzen lassen.

Progress DataXtend SI

Das Produkt Progress DataXtend hilft bei der Integration von Services in eine SOA. Oft wird bei der Planung einer serviceorientierten Architektur der Fehler begangen, sich nur auf die technische Anbindung der Systeme und Protokolle an ein gemeinsames Kommunikationssystem zu konzentrieren. Damit spart man zwar die n:m Integration aller Systeme untereinander, es verbleibt aber das ungelöste Problem wie die Systeme untereinander kommunizieren. Nur weil ich von meinem Handy fast jeden Menschen auf diesem Planeten anrufen kann, heißt das noch lange nicht, dass wir effektiv kommunizieren können, denn wir sprechen nicht die gleiche Sprache. DataXtend ist in dieser Analogie der Langenscheidt des Esperanto, es erlaubt die Verwendung eines Canonical Data Model und dessen Mapping auf die in der SOA befindlichen (Legacy) Services. Die Modellierung erfolgt in der gewohnten Eclipse Umgebung, die um entsprechende Plugins erweitert wird. Zur Laufzeit kann die Datenübersetzung entweder als Service im SOA deployed werden, oder als Adapter zwischen der Service und bzw. dem ESB selbst.

DataXtend kann mit riesigen Modellen wie dem Shared Information und Data (SID) Modell des TeleManagement Forums umgehen und bietet alle Optionen und Feinheiten, die man von einem Modell-Mapper erwartet. Zuzüglich zu der reinen Modellierung bietet es die Möglichkeit Validierungsregeln zu erstellen, und diese auch abtesten zu lassen. Eine Regel könnte sinngemäß lauten: “Wenn die eingehende Nachricht ein Umzug ist, müssen zwei Adressen vorhanden sein”. Es wäre noch interessant zu wissen, in wie weit das auch automatisiert in einer Continuous Integration-Umgebung möglich ist.

Durch das mögliche Deployment der DataXtend SI Runtime Engine als Mapping und Validation Service Engine funktioniert die Integration in einem JBI container relativproblemlos. Dass die SI Engine zusammen mit den notwendigen Mappings direkt aus dem SI Designer exportiert werden kann ist dabei ein hilfreiches Feature.

DataXtend SI muss sich mit schwergewichtigen Produkten wie SAP NetWeaver Master Data Management, IBM InfoSphere Master Data Management Server und der AquaLogic Data Services Platform messen lassen. Vom ersten Eindruck her ist DataXtend von den Möglichkeiten der Modellierung aber gleichauf, zugleich aber flexibler und vor allem leichtgewichtiger in eine SOA integrierbar. Der Ansatz des Master Data Management ist eben eher ein holistischer Natur, bei dem sämtliche Daten in der SOA gekapselt werden, um unterschiedliche Versionen der gleichen Daten zu verhindern. Während dies als Endziel erstrebenswert ist, bietet DataXtend SI die Möglichkeit sich diesem Ziel schrittweise anzunähern.

JavaRebel

Als letzten Punkt der Tagesordnung stellte Carsten Mjartan den JavaRebel vor. Damit werden die Möglichkeiten des hot code replacement in Java erheblich verbessert. Theoretisch gibt es diese Möglichkeit bereits seit dem JDK 1.4 (in IDEs wie dem Visual Age for Java auch schon erheblich länger; für Smalltalk noch viel länger), allerdings beschränkt auf Änderungen, die nicht die Signatur einer Klasse ändern. Mit JavaRebel, das sich als -javaagent in die JVM hängt, erspart man sich Carstens Erfahrung nach einen großen Teil der Server-Redeployments und Neustarts. JavaRebel überwacht dazu die von der IDE generierten Klassen und propagiert die Änderungen in die Laufzeitumgebung, während der Zustand der Anwendung komplett erhalten bleibt. EJBs ändern und im Browser ein Refresh machen, um die neue Logik zu testen? Kein Problem mehr!