Hazelcast
Hazelcast is default implementation for cache / memory-grid because
- mature and feature-rich solution
- not only for caching data but also for computation in clustered environment
- offers first-class Spring support (Spring cache abstraction layer, Spring Boot support, Spring configuration in common)
- does support management tools, like Hazelcast management center
OpenHub framework uses Spring cache abstraction layer or Spring Boot (auto-configuration) for decoupling from specific cache implementation. Then it's possible to use different cache providers (such as Redis, ehCache, ...) without making changes in the code (only configuration).
Nevertheless there are implementations which use directly Hazelcast's features, for example org.openhubframework.openhub.core.throttling.ThrottleCounterHazelcastImpl for throttling counting.
Configuration in OpenHub
There is default Hazelcast configuration in the file config/ohf_hazelcast.xml.
Cluster configuration
By default, hazelcast is configured as standalone single-node. For cluster deployment it should be configured accordingly, see hazelcast specification for more info: (Hazelcast configuration, Cluster - Discovery Mechanisms).
OpenHub framework uses Spring Boot Hazelcast support for auto-configuration. There is parameter spring.hazelcast.config which can change configuration file.
# the location of the configuration file to use to initialize Hazelcast. # the default Hazelcast configuration spring.hazelcast.config=classpath:/config/ohf_hazelcast.xml
Spring Boot supports Hazelcast in two ways:
- direct Hazelcast support for solution itself
- Hazelcast as cache provider that is supported by caching Spring support
Both ways have different configuration Spring Boot parameters: spring.hazelcast.config (has higher priority) vs spring.cache.hazelcast.config
Hazelcast is configured in XML file by default because it's often necessary to change it for target environment - set how instances in the cluster will communicate, set specific data structures etc. That's why OpenHub framework prefer XML configuration to configuration in the code. Nevertheless projects have possibility to directly set-up com.hazelcast.config.Config (that has higher priority than XML configuration).
@Bean public Config hazelCastConfig() { Config config = new Config(); config.set... return config; }
or use org.springframework.boot.autoconfigure.cache.CacheManagerCustomizer:
@Bean public CacheManagerCustomizer hazelCastCacheManagerCustomizer() { return new CacheManagerCustomizer<HazelcastCacheManager>() { @Override public void customize(HazelcastCacheManager cacheManager) { ... } }; }
Data structures configuration
Regardless of sth configuration style (XML vs API) it's necessary to configure data structures which are used in OpenHub framework (or in the project).
There is the full example of Hazelcast configuration with detailed description of all configuration parameters.
The OpenHub framework uses the following data structures:
Name | Data structure type | Usage | Common parameters |
---|---|---|---|
throttling | map | throttling counting | Distributed map for counting throttling.
|
config_params | map | configuration parameters caching | Distributed map for caching configuration parameters.
|
There is org.openhubframework.openhub.core.config.CacheNames class with all defines cache names.