Blog

Alle Beiträge mit dem Tag Java EE

TracEE – der Weg zur finalen Version

Die Entwicklung des Frameworks TracEE schreitet mit großen Schritten voran, so dass wir (Daniel, Tobi und ich) bald die erste Version mit stabiler API herausbringen wollen. Was TracEE genau ist, hatten wir in einem vergangenen Blog-Beitrag bereits sehr ausführlich erwähnt. In wenigen Sätzen erklärt: TracEE erzeugt einen Invocation-Context im MDC und sorgt mit den Bindings dafür, dass dieser bei allen Aufrufen mitgegeben wird. Alle Log-Einträge enthalten diese Informationen und lassen sich so einfach nachvollziehen. Vor allem für das Monitoring von Microservice-Architekturen ist ein solcher MDC in den Log-Meldungen wünschenswert: Ein Frontend-Service empfängt einen Request und ein Filter erzeugt eine InvocationId. Dieser Service ruft zwei weitere Microservices auf, die getrennt deployed werden. Egal ob REST, SOAP oder etwas anderes: TracEE trägt den MDC des Logging-Frameworks weiter — es überträgt den MDC sogar im Response wieder zurück! Wir nennen diese Abbildung TPIC – TracEE Propagated Invocation Context.

In einer Aggregation der Log-Einträge (z.B. über Splunk oder einen ELK-Stack – ElasticSearch, Logstash, Kibana) werden die Zusammenhänge mittels invocationId und (pseudonymisierter) sessionId sichtbar:Log-Statements mit Invocation- und SessionId generiert und übertragen durch TracEE

Durch diese IDs wird überhaupt erst sichtbar, dass Alice auf einen Fehler im Programmablauf aufgelaufen ist — und nicht Bob. Da das Backend z.B. via REST angesprochen wurde, sind die aus Application-Servern bekannten Thread-IDs bei der Korrelation von Log-Meldungen nicht sehr hilfreich.

Reorganisation des TracEE-Projects

TracEE ist und bleibt weiterhin OpenSource und auf GitHub verfügbar. Da wir das Projekt aber nicht als alleiniges Holisticon-Projekt sehen und uns über jegliche Mithilfe, konstruktive Kritik und Code-Beiräge sehr freuen, haben wir das Repository in eine eigene GitHub-Organisation verschoben. Zudem haben wir die Context-Logger aus dem Hauptprojekt herausgelöst und in ein Tochter-Projekt überführt. Auch die Beispiele wurden in ein separates Repository verschoben und helfen dir bei der Integration in deine Projekte.

Apropos Integration: Uns erreichte die Kritik, dass die Dokumentation zwar die Zusammenhänge gut erklärt, die Integration mit den einzelnen Technologien aber überarbeitungswürdig ist. Diese Module heißen Bindings und übertragen z.B. den TPIC von einem Apache CXF-Client auf einen JaxWS-Server. Diese Dokumentation haben wir für sämtliche Bindings nachgepflegt und über die Hauptseite verlinkt. Auch die Unterseite der Bindings enthält die entsprechenden Links.

Neue Funktionen und Refactorings

Des weiteren wurden viele Technologien abseits des JavaEE-Stacks als Binding integriert. Neu seit dem letzten Blog-Artikel sind folgende Integrationen:

  • Spring MVC
  • Apache CXF
  • Quartz-Scheduler
  • Spring AMQP (RabbitMQ)

Diese wurden in Teilen von den ersten early-adoptern implementiert und in Form von Pull-Requests an das TracEE-Projekt gegeben. Interessant an dieser Stelle sind die Quartz-Scheduler. Diese oft für die Batch-Verarbeitung genutzten Jobs werden zeitlich gesteuert und stellen somit eigentlich keinen echten Request dar. Trotzdem möchte man durch einen Job ausgeführte SOAP- oder REST-Anfragen auch diesem Job zuordnen können. Daher haben wir beschlossen, den Begriff RequestId durch das generellere Konzept einer InvocationId abzulösen.

TracEE – What’s next?

Zuallererst: Du integrierst einfach mal TracEE in dein Projekt und berichtest uns und der Welt von den Vorzügen eines einheitlichen Contextes. Bei Fragen und Problemen freuen wir uns auf dein Feedback oder deine Beiträge auf Github. Für die schnelle Hilfe haben wir für TracEE einen Gitter-Kanal eingerichtet.

Außerdem arbeiten wir gerade an einer Integration in Spring WS und überarbeiten gerade die Context-Logger-Struktur. Falls Du noch immer nicht überzeugt sein solltest, kannst du auch auf unsere Blog-Serie warten. In dieser werden wir auf die Vorzüge eines zentralisierten Log-Systems eingehen und zeigen, wie TracEE und Context-Logging dir hilft, z.B. Bugs oder Abläufe über die Systemgrenzen besser nachzuvollziehen. Und irgendwann dann werden wir die 1.0 releasen.

Jetzt geht’s App mit AngularJS

Das Problem kennt jeder Java-Entwickler: Die UI-Berechnungen laufen auf dem Server, der Browser stellt die Inhalte nur dar. Für jede Interaktion mit dem Nutzer wird der Server angefragt. Gerade bei schlechter Internetverbindung sorgt das für ein sehr schlechtes Nutzererlebnis. Der Server muss den Zustand des Clients vorhalten. Damit werden Speicher- und Rechenkapazitäten gebunden. So fühlt sich die Oberfläche immer zäh an. Auch eine Erhöhung der Serverkapazitäten löst das Problem meist nicht.

weiterlesen

TracEE – Log-Analyse in verteilten JavaEE-Anwendungen

Das Nachvollziehen von Systemaufrufen zur Problemanalyse in verteilen JavaEE-Anwendungen anhand von Log-Dateien ist anstrengend und kostet Zeit. Gerade bei der Analyse von Störungen in einer Produktionsumgebung ist man von der Geschwätzigkeit der erzeugten Log-Einträge abhängig. Auch ist man dort eher selten in der Lage, mal eben das Log-Level zu erhöhen – sofern ein zu analysierendes Problem überhaupt reproduzierbar ist.

Heute möchten wir ein neues Framework und Open-Source-Projekt vorstellen, das diesem Problem zu Leibe rückt: TracEE. Aussagen wie „Das kann man jetzt so leider nicht mehr nachvollziehen!“ könnten bald der Vergangenheit angehören.

weiterlesen

Java Heap-Dump-Analyse

Jeder von Euch kennt sicherlich die Situation, dass Java Anwendungsserver sehr viel Speicher benötigen und dort im schlechtesten Fall sogar OutOfMemory-Exceptions auftreten können. Die Ursachen für die hohen Speicheranforderungen können dabei sehr vielfältig sein: sie reichen von konstant wachsenden Systemen über speicherhungrige Anwendungen, die große Mengen an Daten zwischenspeichern, bis zu Fehlerverhalten der Anwendungsserver.

Oftmals wird bei Speicherproblemen leider oft noch der „einfachste“ Weg gewählt, indem dem Anwendungsserver mehr Speicher zugeteilt und nicht weiter nach den eigentlichen Ursachen des hohen Speicherverbrauchs geforscht wird. Dabei ist bei diesem Vorgehen in der Regel unklar, ob damit das ursächliche Problem behoben oder das erneute Auftreten des Problems einfach nur zeitlich herausgezögert wird.

Ein probates Mittel, solche Speicherprobleme zu analysieren und zu beheben, sind dabei Heap-Dumps. Bei einem Heap-Dump handelt es sich dabei um ein zu einem definierten Zeitpunkt erstelltes Speicherabbild der JVM eines Java Programms. Seit der Java-Version 1.6 existiert im JDK ein kleines Tool, das die Erstellung von Heap-Dumps zur Laufzeit des Anwendungsservers ermöglicht.

weiterlesen

Camunda startet eigenes Open Source-Projekt

Schon seit einiger Zeit bietet die camunda services GmbH aus Berlin mit ihrem Produkt „camunda fox“ diverse Erweiterungen zur Open Source Process Engine „Activiti“ an, die den Einsatz von Activiti als Shared Process Engine im Java EE-Umfeld erst sinnvoll möglich machen. Diesen erweiterten Technologie-Stack setzen auch wir in Kundenprojekten bereits erfolgreich ein, und unsere Praxiserfahrungen mit der Plattform sind dabei durchweg positiv. Nicht nur aus technischer Sicht, sondern auch, weil mit camunda ein sehr kompetentes und sympathisches Unternehmen dahinter steht, das einen exzellenten Support bietet.

Vergangene Woche hat camunda nun sein eigenes Open Source-Projekt gestartet: camunda.org. Als Fork von Activiti wird aus „camunda fox“ nun die „camunda BPM Plattform“, und viele der Enterprise-Features, die bisher nicht von Activiti adressiert wurden, wandern in die neue Open Source Software (wenngleich es für Unternehmen nach wie vor eine kostenpflichtige Enterprise-Edition mit entsprechendem Support, erweiterter Qualitätssicherung und zusätzlichen Features gibt).

In diesem Zug hat auch Holisticon seine Partnerschaft mit camunda vertieft. Als qualifizierter Service-Provider unterstützen wir BPM/SOA-Projekte, die auf camunda BPM als technische Plattform setzen. Jakob Freund, Geschäftsführer von camunda, sagt dazu: „Holisticon ist ein innovatives, leistungsstarkes und zugleich sehr sympathisches Unternehmen. Wir freuen uns über die bereits bestehende, erfolgreiche Zusammenarbeit in Kundenprojekten und natürlich besonders darüber, dass wir mit Holisticon einen kompetenten Partner an unserer Seite wissen, der das camunda BPM-Projekt mit uns voranbringen und die Verbreitung im Markt unterstützen wird.“