Archive for the ‘Java’ Category
Page 1 of 3 1 2 3
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!

Arquillian 1.0

Sehr verehrte Damen und Herren, liebe Java-Geeks,

es ist mir eine Freude, Ihnen heute mitteilen zu können, dass die 1.0-Version des bekannten und beliebten Arquillian-Testframeworks veröffentlicht wurde. Bitte aktualisieren Sie JETZT ihre Maven-Dependencies.

Mit freundlichen Grüße,

Sascha Möllering

{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!

Instrastructure as code, Teil 1

Durch meine bisherigen Jobs habe ich eine hohe Affinität zu RedHat, bis vor ein paar Wochen war mein Standardansatz, um Software und Konfiguration deployen folgender: die Software als RPM bereitstellen, in den Satellite hochladen und die Konfiguration dort ablegen. Dann habe ich Chef und das Konzept “Infrastructure as code” kennengelernt. Infrastruktur wird als Programmieren begriffen und die best practices (Versionsverwaltung, etc.) übernommen. Das Aufsetzen der Datenbank, eines Application-Servers und des Web-Servers wird somit zu einer Implementierungsaufgabe. Da die Infrastruktur als Code vorliegt, kann dieser – wie anderer Code auch – in einem Versionierungssystem verwaltet werden, was zusätzlich Vorteile in Bezug auf Nachvollziehbarkeit bedeutet.

{lang: 'de'}

flattr this!

JMS Clustering mit EAP 5

In der Vergangenheit habe ich mich ja bereits öfters mit dem Clustering des JBoss Application Servers beschäftigt, doch das JMS-Clustering mit Anpassung der entsprechenden JEE-Services war eine Premiere. Ausgangspunkt war, dass wir mehrere JEE-Services auf MDB-Basis hatten, die die interne HSQL-DB genutzt haben. Diese Services sollten ausfallsicher laufen. Aus diesem Grund haben wir uns für ein “echtes” Clustering der Message-Queues mit einer zentralen Datenbank-Instanz entschieden.

{lang: 'de'}

flattr this!

EJB3: Automatisches Erstellen von Queues bei MDBs

Vor ein paar Tagen hatte ich ein interessantes Problem: bei JBoss 4 war es sehr einfach, Queues für MDBs zu erzeugen. Einfach destination und destinationType in die @ActivationConfigProperty eintragen und beim Deployment werden werden die Queues automatisch erzeugt. Leider ist das bei JBoss 5 nicht mehr ganz so einfach. Der Trick ist, in der jboss.xml das Tagtruehinzuzufügen und auf die entsprechende EJB und die anzulegende Queue zu verweisen (die jboss.xml liegt im META-INF-Verzeichnis). Im Ganzen sieht das folgendermaßen aus:

<?xml version="1.0" encoding="UTF-8"?>
<jboss xmlns="http://www.jboss.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss_5_0.xsd"
version="3.0">
<enterprise-beans>
<message-driven>
<ejb-name>QueueCreateMDB</ejb-name>
<destination-jndi-name>queue/myQueue</destination-jndi-name>
<create-destination>true</create-destination>
</message-driven>
</enterprise-beans>
</jboss>

Die dazu passende MessageBrivenBean sieht so aus:

@MessageDriven(name="QueueCreateMDB", activationConfig={
@javax.ejb.ActivationConfigProperty(propertyName="destinationType", propertyValue="javax.jms.Queue"),
@javax.ejb.ActivationConfigProperty(propertyName="destination", propertyValue="queue/myQueue"),
@javax.ejb.ActivationConfigProperty(propertyName="useDLQ", propertyValue="false"),
@javax.ejb.ActivationConfigProperty(propertyName="acknowledgeMode", propertyValue="Auto-acknowledge")},
messageListenerInterface=MessageListener.class)

public class QueueCreateMDB implements MessageListener {

Dadurch wird beim Deployment die angegebene Queue angelegt.

{lang: 'de'}

flattr this!

JON 3 und Alerts

Ich sollte Beta-Tester bei RedHat werden: ich habe drei Cases im Support-Portal aufgemacht und es sind zwei Bugs aufgemacht worden. Dieses Mal habe ich einen OutOfMemory-Alert aufgesetzt: Ziel war es, dass ein Alert ausgelöst wird, wenn ein java.lang.OutOfMemory-Error im server.log-file des JBoss auftaucht. Dazu habe ich einen Alert und einen entsprechenden Recovery Alert definiert. Problem war: der Recovery Alert hat nicht gezogen. Das Problem war, dass ich die Availability des Recovery Alerts auf “Comes up” gesetzt habe, was offensichtlich nicht funktioniert. Ein Workaround ist, dass ein zusätzlicher Event auf den Start des App-Servers gelegt wird (“Started in:”), was aber sehr unschön ist, da der JON dann mit Events zugespamt wird. Wie dem auch sei: hier ist der Bug zu finden.

Update: Hach, geht auch nicht … so muss es sein: bei “Condition” muss “Operation Execution [restart] with result status [SUCCESS]” eingestellt werden, dann geht es. Darüber hinaus hatte ich das Problem, dass der Restart immer Timeouts bekommen hat, nach dem Ändern der Log4j-Konfiguration (!!!) hat es dann funktioniert. Sehr sonderbar, zumal der Restart als Skript implementiert ist und explizit nicht über JMX. Irgendwie macht mir das ernsthaft Bauchschmerzen …

{lang: 'de'}

flattr this!

Plugins für JON … und Maven

Diese Woche habe ich ein wenig mit JON 3 rumgespielt und wollte natürlich auch ein kleines Plugin schreiben. Also habe ich mir eine working copy des Git-Repositories von RHQ ausgecheckt und versucht, die “samples” mit “mvn install” zu bauen. Leider musste ich feststellen, dass das nicht funktioniert:


[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for org.custom:simplereport-serverplugin:jar:1.0-SNAPSHOT
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 91, column 18
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building RHQ Simple Report Server Plugin 1.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) @ simplereport-serverplugin ---
[INFO] Deleting C:\data\git\rhq\simplereport-serverplugin\target
[INFO]
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ simplereport-serverplugin ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] Copying 1 resource
[INFO]
[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ simplereport-serverplugin ---
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. build is platform dependent!
[INFO] Compiling 1 source file to C:\data\git\rhq\simplereport-serverplugin\target\classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------

Meine erste Annahme war, dass ich irgendwo einen Fehler gemacht habe, die pom-Files sahen aber in Ordnung aus, also habe ich mich an den RedHat-Support gewandt. Ergebnis: das ist leider ein Bug, der immer auftritt, wenn kein RHQ-Maven-Repository vorhanden ist bzw. wenn dieses leer ist. Sehr unschön.

{lang: 'de'}

flattr this!

Page 1 of 3 1 2 3
Viewing Options List View Grid View