Recently i needed a cache for a JavaEE project with the following requirements almost zero rampup time, throughput >250000 ops/s and
kind of big data (>4g) and since I am a big fan of Chronicle-Map and it covers the requirements
i tried to use it right away. This post describes a failure at deploy time if you use ChronicleMap right away and provides a
solution to overcome this issue.
The following demo repository (https://github.com/AlexBischof/chroniclemap-wildfly)
contains two maven modules. The first one creates a cache (MyMap.class) with a CM containing postalcodes which are persisted into a file (test.dat).
For demo purposes it only contains 19 samples.
Within the second module
i created a JavaEE singleton which simply opens MyMap.
Now if you deploy that WAR for example with a wildfly (also configured within that module) you will get the following error.
The problem is relatively simple. CM does some dynamic compilation under the hood and this results in problems with the classloader of the application server. Unfortunately there
is no way (at least not known to me) to configure the class loader in that way the application server can be satisfied. But there is a kind of messy workaround which involves
the following manual steps:
Set system property chronicle.values.dumpCode=true during CM file creation. Now you can see all the generated classes on System.out
Manually seperate the classes and copy that output into the respective packages (e.g. net.openhft.chronicle.hash.VanillaGlobalMutableState$$Native)
That way you kind of pollute your source code but it works without failures. The following screenshot displays the generated classes
in the demo project.