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 2018/02/21 13:24:00 UTC

[jira] [Commented] (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:comment-tabpanel&focusedCommentId=16371400#comment-16371400 ] 

Serge Huber commented on UNOMI-166:
-----------------------------------

We found an issue with the cache because some parts of Unomi rely on reading a version of a document immediately after saving it, and because of the cache the version is not available until the entry has expired. 

A solution could be to avoid caching during startup of Unomi, or to use shorter time-to-idle settings

> 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: Improvement
>          Components: core
>    Affects Versions: 1.3.0-incubating
>            Reporter: Serge Huber
>            Assignee: Serge Huber
>            Priority: Major
>             Fix For: 1.3.0-incubating
>
>
> 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
(v7.6.3#76005)