You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@unomi.apache.org by "Serge Huber (Jira)" <ji...@apache.org> on 2020/02/04 08:38:00 UTC

[jira] [Updated] (UNOMI-166) Experiment : introduce a back-end cache for the ElasticSearch persistence manager

     [ https://issues.apache.org/jira/browse/UNOMI-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Serge Huber updated UNOMI-166:
------------------------------
        Parent: UNOMI-266
    Issue Type: Sub-task  (was: Improvement)

> 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: core
>    Affects Versions: 1.3.0-incubating, 1.4.0
>            Reporter: Serge Huber
>            Assignee: Serge Huber
>            Priority: Major
>             Fix For: 1.5.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.3.4#803005)