Skip to content

Asynchrones Laden in Guava Cache

Posted by Bernd Eckenfels on
Google Guava Cache ist eine weitverbreitete Komponente zur Implementierung von caches. Sie bietet ein Framework um schnell in-memory caches zu implementieren. Unter anderem erlaubt ein CacheLoader den asynchronen refresh von Einträgen. Dabei muss man aber beachten, dass dies nicht out-of-the-box geschieht, sondern dass man dazu eine eigene Logik implementieren muss die das refreshen/laden im Hintergrund implementiert.

Die Grundlagen sind im Guava Wiki beschreiben, ich hab aber aktuell ein Issue offen in dem ich die Dokumentation einer bestehenden Hilfsmethode vorschlage:

Ein kleiner Wrapper wird von Google seit Guava 17 bereitgestellt, man kann damit einen synchronen CacheLoader der keine besondere async-logik enthält wrappen, so dass die refreshes an einen Executor delegiert werden: CacheLoader.asyncRefresh().

Damit lässt sich schnell aus einem vorhandenen CacheLoader ein asynchroner machen. Dabei ist zu beachten dass der Wrapper zusätzliche Objekte erstellt bei jedem re-fresh. Wenn es also auf leichtgewichtige Implementierung ankommt, und wenn eventuell ein Teil des Refresh codes synchron laufen kann, so ist es besser die Logik selbst zu implementieren (man muss nur darauf achten die Erstellung der Future erfolgt synchron, alles was bis zur completion ausgeführt wird läuft im Hintergrund und verzögert keine Lookups).

Folgende Eigenheiten hat das Refreshing:

  • Wenn das Refreshing mittels cache.refresh("key") angestoßen wird, so wartet der refresh Aufruf bis der CacheLoader fertig ist (genauer gesagt, bis die reload future zurückgegeben wurde). Das blockiert nur den Aufrufer-thread, alle anderen Threads die in der Zwischenzeit Cache lookups (für den gleichen Key) machen, bekommen den noch gecachten (alten) Wert.
  • Wenn ein Cache invalidiert wird oder ein Wert aus dem Cache expired, so gibt es keinen alten bestehenden Wert und jeder folgende lookup wird auf das Ende des CacheLoader.load warten müssen. Dabei wird der load pro Key nur einmal gestartet und alle anderen Threads die in dem Zeitraum den Wert anfordern werden angehalten - das ist gut da es die Parallelität des CacheLoader anfragen limitiert. Diese Methode wird nicht in einer asynchronen Variante gewrapped.
  • Wenn refreshing nicht wegen einem direkten refresh(key) Aufruf notwendig wird sondern durch ablaufen des refreshAfterWrite() Zeitraums, so wird das Refreshing durch den nächsten lookup angestoßen. Wenn der CacheLoader synchron ist wird dies auch den (zufällig nächsten) lookup Thread so lange blockieren. Alle weiteren Lookups werden nicht blockiert sondern bekommen den alten Wert. D.h. man muss hier mit regelmäßigen einzelnen verzögerten Lookups rechnen und man kann nicht davon ausgehen dass die Anfragereihenfolge klar in "alte Werte - neue Werte" sortiert werden kann.

The Porting to 11 Theory - The QName Distraction

Posted by Bernd Eckenfels on

If you have been using Java for quite some time (since 1.4) and wanted to maintain binary data compatibilitiy, chances are high, that you are relying on the com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 system property. This will ensure your JVM creates and reads serialized javax.xml.namespace.QName Objects with the same serialisation version UID compatibleSerialVersionUID = 4418622981026545151L. This is especially needed, if you use serialization to store or transmit object trees containing XML objects (and you did not serialize the XML to actual text).

The actual serialVersionUID of QName is meanwhile -9120448754896609940L, but with the compatibility hack you did not only generate objects with the compatible version, but also accepted them.

When you move to Java beyond 8 however, this might break. The backward compatible logic has been removed in JAXP of Java 11. This means your QName instances saved with a not so old Java runtime of 8 (but with the compatibility flag set), suddenly do not work anymore.

Bummer. This is one of the reasons why it is important to follow up on such compatibility hacks and fix them for good. Otherwise it will bite you when you port to newer Java versions just a few decades later.

In JDK11 the compatibility function was removed, with a somewhat sarcastic comment:

  // tests show that the ID is the same from JDK 1.5 through JDK 9
  private static final long serialVersionUID = -9120448754896609940L;

Certainly JDK 1.5 up until 10 did use the default UID, but not if you had used the compatibility flag the whole time.

So the following test code will demonstrates the servialVersionUIDs returned by different Java versions, with and without the compat flag:

Runtime: OpenJDK 64-Bit Server VM 1.8.0_212-b04/25.212-b04 on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
Created QName: {http://eckenfels.net}bernd  with UID 4418622981026545151
Serialized: rO0ABXNyABlqYXZheC54bWwubmFtZXNwYWNlLlFOYW1lPVIaMLx2_f8CAA...dAAA

Runtime: OpenJDK 64-Bit Server VM 1.8.0_212-b04/25.212-b04 on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=N/A
Created QName: {http://eckenfels.net}bernd  with UID -9120448754896609940
Serialized: rO0ABXNyABlqYXZheC54bWwubmFtZXNwYWNlLlFOYW1lgW2oLfw73WwCAA...dAAA


Runtime: OpenJDK 64-Bit Server VM 11.0.1+13-LTS/11.0.1+13-LTS on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=N/A
Created QName: {http://eckenfels.net}bernd  with UID -9120448754896609940
Serialized: rO0ABXNyABlqYXZheC54bWwubmFtZXNwYWNlLlFOYW1lgW2oLfw73WwCAA...dAAA

Runtime: OpenJDK 64-Bit Server VM 11.0.1+13-LTS/11.0.1+13-LTS on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0
Created QName: {http://eckenfels.net}bernd  with UID -9120448754896609940
Serialized: rO0ABXNyABlqYXZheC54bWwubmFtZXNwYWNlLlFOYW1lgW2oLfw73WwCAA...dAAA

As you can see, on the JDK11 the compat flag is ignored: only the new default serialVersion UID is used.

With a little modified ObjectInputStream (and there are many reasons to have a custom OIS, like this replacement, but also for hooking into modularized classloaders or doing object filtering) all variantes can be read without the need for a compat flag:

Runtime: OpenJDK 64-Bit Server VM 1.8.0_212-b04/25.212-b04 on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0

Deserialize Old
 Default OIS read: {http://eckenfels.net}bernd
 My OIS read: {http://eckenfels.net}bernd

Deserialize Default
 Default OIS failed: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = -9120448754896609940, local class serialVersionUID = 4418622981026545151
 My OIS read: {http://eckenfels.net}bernd


Runtime: OpenJDK 64-Bit Server VM 11.0.1+13-LTS/11.0.1+13-LTS on Windows 10 10.0
 com.sun.xml.namespace.QName.useCompatibleSerialVersionUID=N/A

Deserialize Old
 Default OIS failed: java.io.InvalidClassException: javax.xml.namespace.QName; local class incompatible: stream classdesc serialVersionUID = 4418622981026545151, local class serialVersionUID = -9120448754896609940
 My OIS read: {http://eckenfels.net}bernd

Deserialize Default
 Default OIS read: {http://eckenfels.net}bernd
 My OIS read: {http://eckenfels.net}bernd

The code for this tester can be found in a GitHub Gist (including test vectors and complete sample output).