Archive for the ‘Systemheldentum’ Category
Page 1 of 1 1
Viewing Options List View Grid View

JBoss-Cache und Eviction-Strategien

Vor ein paar Tagen habe ich die Anfrage bekommen, eine bestimmte Region für den Hibernate 2nd level-cache zu konfigurieren, die es ermöglicht, Entities nach 2 Minuten aus dem Cache zu schmeissen. Gut, habe ich mir gedacht, das sollte kein Problem sein, einfach im JBoss Cache eine neue Region definieren, fertig. Leichter gesagt als getan … das Problem ist, dass man eine Menge von Beispielen für den standalone-cache findet, aber für den im JBoss integrierten … sehr dünn. Letztendlich habe ich es dann doch hinbekommen, meine mvcc-entity in jboss-cache-manager-jboss-beans.xml sieht folgendermaßen aus:


<entry><key>mvcc-entity</key>
<value>
<bean name="MVCCEntityCache" class="org.jboss.cache.config.Configuration">

<!-- Node locking scheme -->
<property name="nodeLockingScheme">MVCC</property>
<!-- READ_COMMITTED is as strong as necessary for most
2nd Level Cache use cases. -->
<property name="isolationLevel">READ_COMMITTED</property>
<property name="useLockStriping">false</property>

<!-- Mode of communication with peer caches.
INVALIDATION_SYNC is highly recommended as the mode for use
with entity and collection caches. -->
<property name="cacheMode">INVALIDATION_SYNC</property>

<!-- Name of cluster. Needs to be the same for all members -->
<property name="clusterName">${jboss.partition.name:DefaultPartition}-mvcc-entity</property>
<!-- Use a UDP (multicast) based stack. A udp-sync stack might be
slightly better (no JGroups FC) but we stick with udp to
help ensure this cache and others like timestamps-cache
that require FC can use the same underlying JGroups resources. -->
<property name="multiplexerStack">${jboss.default.jgroups.stack:udp}</property>
<!-- Whether or not to fetch state on joining a cluster. -->
<property name="fetchInMemoryState">false</property>

<!-- The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members at startup. Ignored if FetchInMemoryState=false. -->
<property name="stateRetrievalTimeout">60000</property>

<!-- Number of milliseconds to wait until all responses for a
synchronous call have been received. -->
<property name="syncReplTimeout">17500</property>

<!-- Max number of milliseconds to wait for a lock acquisition -->
<property name="lockAcquisitionTimeout">15000</property>

<!-- Hibernate 2LC can replicate custom types, so we use marshalling -->
<property name="useRegionBasedMarshalling">true</property>
<!-- Must match the value of "useRegionBasedMarshalling" -->
<property name="inactiveOnStartup">true</property>

<!-- Disable asynchronous RPC marshalling/sending -->
<property name="serializationExecutorPoolSize">0</property>
<!-- We have no asynchronous notification listeners -->
<property name="listenerAsyncPoolSize">0</property>

<property name="evictionConfig">
<bean class="org.jboss.cache.config.EvictionConfig">
<property name="wakeupInterval">5000</property>
<!-- Overall default -->
<property name="defaultEvictionRegionConfig">
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<!-- Evict LRU node once we have more than this number of nodes -->
<property name="maxNodes">10000</property>
<!-- And, evict any node that hasn't been accessed in this many seconds -->
<property name="timeToLiveSeconds">1000</property>
<!-- Don't evict a node that's been accessed within this many seconds.
Set this to a value greater than your max expected transaction length. -->
<property name="minTimeToLiveSeconds">120</property>
</bean>
</property>
</bean>
</property>
<property name="evictionRegionConfigs">
<list>
<!-- Don't ever evict modification timestamps -->
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/TS</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.NullEvictionAlgorithmConfig"/>
</property>
</bean>
<bean class="org.jboss.cache.config.EvictionRegionConfig">
<property name="regionName">/myprefix/com/mycompany/entities/Account</property>
<property name="evictionAlgorithmConfig">
<bean class="org.jboss.cache.eviction.LRUAlgorithmConfig">
<property name="maxNodes">10000</property>
<property name="timeToLiveSeconds">120</property>
<property name="minTimeToLiveSeconds">60</property>
</bean>
</property>
</bean>
</list>
</property>
</bean>
</property>
</bean>
</value>
</entry>

Im Grunde genommen ist es ganz simpel: einfach eine neue Region unter evictionRegionConfigs konfigurieren …

{lang: 'de'}

flattr this!

Hibernate 2nd-level-cache und Clustering

Jeder, der sich früher oder später mit dem JBoss ernsthaft beschäftigt, wird – früher oder später – auf die etwas spezielle Kombination Hibernate 2nd-level-cache und Clustering stoßen. Falls die Default-Einstellungen nicht geändert werden, wird der geneigte Admin mit an Sicherheit grenzender Wahrscheinlichkeit folgende (oder eine ähnliche) Exception bzw. Warning im server.log-file finden:


[org.jboss.cache.interceptors.OptimisticTxInterceptor] Caught exception, will now set transaction to roll back
org.jboss.cache.optimistic.DataVersioningException:

Das Problem besteht darin, dass als Default-Locking-Stratgie Optimistic Locking für den Cache definiert ist. Das kann gelöst werden, indem explizit mvcc als Strategie definiert wird. In die persistence.xml muss dazu folgender Eintrag hinzugefügt werden:


<property name="hibernate.cache.region.jbc2.cfg.entity" value="mvcc-entity"/>
<property name="hibernate.cache.region.jbc2.cfg.collection" value="mvcc-entity"/>

{lang: 'de'}

flattr this!

JON 3.0.1 und mehrere Alerts

Wenn man den JON aufsetzt, kommt man irgendwann zu dem Punkt, Alerts zu definieren, um z.B. OutOfMemoryError und wegbrechenden JVMs aktiv behandeln zu können. Zu diesem Zweck hatte ich zwei Alerts mit Restarts und entsprechenden Recovery-Alerts definiert. Das Problem war aber, dass bei einem OOM-Error beide Alerts gezogen haben und die entsprechende JBoss-Instanz zwei mal restartet wurde. Sehr unschön das.
Die Lösung für das Problem ist, statt zwei einfach einen Alert zu definieren, bei dem beide Kriterien definiert werden und bei dem der Eintritt eines Kriteriums ausreicht.

{lang: 'de'}

flattr this!

BEDCon 2012

So, ich habe es tatsächlich noch geschafft, in den JavaEE-Track der BEDCon 2012 zu rutschen und habe ein paar Worte zu JBoss 7/EAP 6 fallen lassen. Leider war ich nicht so optimal vorbereitet wie ich hätte sein können, da ich die Woche vorher beruflich im Ausland war … wie dem auch sei, für die erste Konferenz war es ganz ok denke ich. Nächstes Ziel ist die W-JAX :-) Ich habe die Slides mal zu Slideshare hochgeladen. Eine Kollegin hat audiotechnisch mitgeschnitten, ich bin gespannt.

{lang: 'de'}

flattr this!

Angriff der Mond-Nazis!

Oder so ähnlich … was ich eigentlich sagen wollte: Iron Sky ist fertig, no shit!

Und der Film wird bei der Berlinale gezeigt, ist das nicht großartig, hach ….

Und hier ist der Constantin Gonzalez kurz zu sehen, wie klein die Welt doch ist.

{lang: 'de'}

flattr this!

BED-Con

Ich habe eben zum ersten Mal einen Vorschlag für einen Talk eingereicht und zwar bei der BED-Con 2012. Thema des Talks ist (natürlich) der JBoss 7 und wie die Neuerungen des Application Servers im Alltag sinnvoll nutzbar sind. Drückt mir die Daumen, dass das Komitee den Vorlschlag annimmt.

{lang: 'de'}

flattr this!

JBoss 7 und Arquillian

Das Testen von J2EE war ja immer pain in the ass, dass kam JEE mit EJB 3, alles war ein POJO und siehe da: man brauchte keinen Application-Server mehr, um seine Logik zu testen (in den meisten Fällen zumindest). Dann kam Arquillian, weil man sah, dass man ggf. doch mal einen Application-Server benötigt für sinnvolle Tests. “Arquillian enables you to test your business logic in a remote or embedded container”, so steht es auf der Webseite und da ich ein ungeduldiger Mensch bin, der immer mit dem blutige-Kante-Spielzeug spielen möchte, habe ich mir vorgenommen, Arquillian zusammen mit dem JBoss 7 CR1b zu testen. Nach einem guten Tag, diversen Flüchen und viel Google-Magic hatte ich dann endlich eine lauffähige Variante implementiert. Als zusätzliche Schwierigkeit habe ich mir gedacht, dass eine Maven-Integration eine feine Sache sei. Problematisch war auch, dass die Arquillian-Doku auf der Webseite etwas veraltet ist, was die Problemlösung signifikant erschwert hat. Wie dem auch sei, im Folgenden ist mein Ansatz zu sehen:

1) Ich habe mir nicht die Mühe gemacht, die Dependencies der einzelnen Maven-Module per Hand aufzulösen (mit den unterschiedlichen Versionen), glücklicherweise gibt es ein DependencyManagement-Modul für Arquillian:

<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.0.0.CR7</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>

2) Die einzelnen Dependencies lauten wie folgt:

<dependency>
<groupId>org.jboss.as</groupId>
<artifactId>jboss-as-arquillian-container-managed</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.protocol</groupId>
<artifactId>arquillian-protocol-servlet</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.junit</groupId>
<artifactId>arquillian-junit-container</artifactId>
<scope>test</scope>
</dependency>

In diesem Fall habe ich die managed-Variante (eine andere JVM, der selbe Rechner) genommen, weil embedded-Variante (die selbe JVM) zur Zeit nicht implementiert ist. Ich hoffe, das ändert sich noch.

3) Meine arquillian.xml-Datei sieht folgendermaßen aus:

>?xml version="1.0" encoding="UTF-8"?>
>arquillian xmlns="http://jboss.org/schema/arquillian"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
>engine>
>property name="deploymentExportPath">target>/property>
>/engine>
>container qualifier="jbossas7">
>protocol type="jmx-as7">
>property name="executionType">REMOTE>/property>
>/protocol>
>configuration>
>property name="javaHome">C:/Java/jdk1.6.0_27>/property>
>property name="jbossHome">C:/jboss-as-7.1.0.CR1b>/property>
>property name="managementAddress">127.0.0.1>/property>
>property name="managementPort">9999>/property>
>/configuration>
>/container>
>/arquillian>

4) Meine persistence.xml-Datei war – mehr oder weniger – eine Standard-Datei, die auf die hsqldb verwiesen hat.
Der eigentliche Test war etwas komplexer, z.B. habe ich statt @EJB die CDI-Annotation @Inject verwendet, da die andere Annotation nicht funktioniert hat. Mein Template für Testklassen sieht folgendermaßen aus:


@RunWith(Arquillian.class)
public class FooBarDaoArqTest {

@Deployment
public static JavaArchive createTestArchive() {

return ShrinkWrap
.create(JavaArchive.class, "test.jar")
.addClasses(FooBarDao.class, ...)
.addAsManifestResource(
new File("src/test/resources/persistence.xml"),
ArchivePaths.create("persistence.xml"))
.addAsManifestResource(EmptyAsset.INSTANCE, ArchivePaths.create("beans.xml"));

}

@Inject
private FooBarDao dao;

@PersistenceContext(unitName = "ExampleDS")
private EntityManager em;

@Before
public void setUp() throws Exception {
HibernateEntityManager hem = em.unwrap(HibernateEntityManager.class);
Session session = hem.getSession();
...
}

@Test
public void testCRUD() throws Exception {
...
}

Damit ist es nun möglich, Arquillian mit JBoss 7 CR1b und Maven zu verheiraten.

{lang: 'de'}

flattr this!

Der Umzug nach Berlin

Jetzt ist es so weit, die letzten zwei Tage habe ich Kisten gepackt “like a boss”, d.h. wenig Schlaf, viel Muskelkater … heute um 06:30 kam der große Umzugswagen und die Jungs vom Umzugsunternehmen haben den in 2,5 Stunden bepackt, in 8 Stunden waren sie in Berlin und um 22:00 war alles aufgebaut, Respekt!

Morgen ist mein letzter “richtiger” Tag in München, übermorgen fahre ich bereits nach Berlin. Meinen Münchner Jahre enden so wie sie angefangen haben: in einem Hotel … ich war jetzt fast 9 Jahre in München und habe habe großartige Leute kennengelernt (meine Frau, meinen ehemaligen Projektmanager bei Accenture, von dem ich viel lernen konnte, meinem ehemaligen Chef bei Softlab/Cirquent, mit dem ich viel lieber mehr Projekte gemacht hätte, meine Kollegen bei der Allianz, die Podcaster vom Heldenfunk, etc.) und viele schöne Projekte hier gehabt. In München haben meine beiden Kinder das Licht der Welt erblickt (beide im Klinikum der LMU Frauenklinik Maistraße) und auf dem Gutshof Menterschwaige haben meine Frau und ich geheiratet. Trotz all dieser Ereignisse bin ich mit der Stadt nie wirklich warm geworden: das einzige, das ich vermissen werde, wird wohl die Nähe zu Norditalien sein (ich liebe Meran).

Ich freue mich wirklich unglaublich auf Berlin: die Stadt, die Menschen und mein großartiger neuer Job!

{lang: 'de'}

flattr this!

Elastic JBoss: Customized JBoss

Die letzten Tage habe ich damit verbracht, auf Basis von CentOS 6.0 (ich denke, ich werde noch auf CentOS 6.1 updaten) eine angepasst JBoss 6 AS-Version zu bauen, die die notwendigen Voraussetzungen für einen stabilen Betrieb in EC2 ermöglicht. Was die Security betrifft, habe ich die JMX- und Admin-Console mit verschlüsselten Passwörtern abgesichert. In der login-config.xml muss dazu folgendes angepasst werden:

<module-option name="usersProperties">props/jmx-console-users.properties</module-option>
<module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
<module-option name="hashAlgorithm">MD5</module-option>
<module-option name="hashEncoding">base64</module-option>

Die entsprechend verschlüsselten Passwörter müssen natürlich in jmx-console-users.properties abgelegt werden. Zusätzlich muss in der web.xml des jmx-console.war-files noch das enstprechende security-constraint aktiviert werden und in der jboss-web.xml noch die security-domain aktiviert werden. Ich denke, ich werde noch die IP-Adressen der Rechner mitloggen, die vesuchen, auf jmx- oder admin-console zugreifen.

Eine der wichtigsten Änderungen ist das Startskript, das ich für den JBoss verwende:

  • Es wird ein PID-File angelegt, das verhindert, dass die JBoss-Instanz zweimal gestartet werden kann
  • Das Binding habe ich in ein Properties-File ausgelagert, da ich mir nicht sicher bin, ob ich das 0.0.0.0-Binding in EC2 so weiterführen kann
  • Die Log-Dateien werden rolliert, damit ich auch nach Restarts alle notwendigen Informationen habe
  • Der Status des JBoss kann abgefragt werden
  • Da die jmx-console abgesichert ist, funktioniert der im Auslieferungszustand aktivierte Stop-Mechanismus nicht mehr korrekt, es müssten immer die Credential mitgegeben werden, deswegen arbeite ich an dieser Stelle lieber mit Unix-kill-Kommandos

Ich denke, zusätzlich werde ich noch einbauen, dass die Log-Dateien eines Tages in ein Archiv komprimiert werden, was die Analyse einzelner Tage sinigfikant einfacher macht.

Die run.conf-Datei habe ich direkt in das Profil gezogen, die Datei liegt jetzt unter default/conf, zusätzlich habe ich noch eine custom-run.conf angelegt, mit der ich Werte der run.conf-Datei überschreiben kann, falls notwendig.

Um ein sauberes Deployment garantieren zu können, habe ich ein zusätzliches Deploy-Verzeichnis angelegt, in dem später die Applikationen liegen sollen. Mit diesem Konstrukt ist es ohne Probleme möglich, zuerst alle Dateien im Deploy-Verzeichnis zu löschen und dann sauber neu zu deployen, was sinnvoll ist, falls Dateien aus dem Deployment entfernt werden.

Die bislang letzte Änderung war die Erstellung eines Startup-Skriptes für /etc/init.d, falls der Server runtergefahren wird. In diesem Skript wird in switch-user auf den jboss-User durchgeführt und das default-Profil des JBoss gestartet.

Das sind bislang alle Änderungen, die ich vorgenommen habe, mehr benötige ich zur Zeit noch nicht, die mod_cluster-Konfiguration mache ich, wenn der RHQ-Server sauber läuft und der Apache korrekt aufgesetzt ist.

{lang: 'de'}

flattr this!

Heldenfunk 63

Wir haben wieder gepodcastet, dieses Mal haben wir uns über Solaris 11 und warum Linux kein OS, sondern eine soziale Bewegung ist, unterhalten. Und dann gibt’s noch Jobs bei Travian Games und censhare für euch, damit betonen wir unseren Dienstleistungscharakter :-) Und dieses Mal

Heldenfunk 63

{lang: 'de'}

flattr this!

Page 1 of 1 1
Viewing Options List View Grid View