[
https://issues.apache.org/jira/browse/UNOMI-166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17610391#comment-17610391
]
Serge Huber commented on UNOMI-166:
-----------------------------------
Not sure if this is a good idea anyway as it will not be scalable to introduce
caches that will require some form of distribution. Maybe adding a double
persistence mechanism to a shared resource such as MongoDB or other might be
better.
> Experiment : introduce a back-end cache for the ElasticSearch persistence
> manager
> ---------------------------------------------------------------------------------
>
> Key: UNOMI-166
> URL: https://issues.apache.org/jira/browse/UNOMI-166
> Project: Apache Unomi
> Issue Type: Sub-task
> Components: unomi(-core)
> Affects Versions: unomi-1.3.0-incubating, unomi-1.4.0
> Reporter: Serge Huber
> Assignee: Serge Huber
> Priority: Major
> Fix For: unomi-3.0.0
>
>
> Given the slow performance of the ElasticSearch back-end for load and save
> operations, it would be an interesting idea to look at using a back-end cache
> to absorb the load until ElasticSearch can process the requests.
> Also, introducing such a cache would make it possible to use bulk processing
> to process save requests, while still making the saved objects immediately
> available since they are immediately available in the cache.
> The cache could be implemented using Hazelcast, which is already available
> since it is used by Karaf Cellar.
> Based on the result of this experiment the cache could be activated by
> default (if no serious issues are found during the experiment), or removed
> and replaced by some other solution.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
