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

Kevan Jahanshahi resolved UNOMI-741.
------------------------------------
    Resolution: Fixed

> Session/Event index rollover: Session retrieval strategy
> --------------------------------------------------------
>
>                 Key: UNOMI-741
>                 URL: https://issues.apache.org/jira/browse/UNOMI-741
>             Project: Apache Unomi
>          Issue Type: Task
>            Reporter: Kevan Jahanshahi
>            Priority: Major
>             Fix For: unomi-2.2.0
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> -Following performance tests done on ticket: 
> https://issues.apache.org/jira/browse/UNOMI-725-
> -We need to implement sessionId/indexName affinity cache to speed up access 
> to current user session on context requests.-
> -Due to the nature of the splitted indices for the sessions it's not possible 
> to know where exactly is stored the sessionId from the context request.-
> -We can do a query like it is right now but as shown in the performances 
> results test this is impact a lot the performance for concurrent context 
> requests.-
> -So we need to implement a sessionId/indexName affinity cache in the 
> persistence service to speed up the loading of current user sessions.-
> -consider a cache system with a time-to-idle feature that will automatically 
> clean the unused sessionId after 30min and make this configurable.-
> -PoC PR:- [-https://github.com/apache/unomi/pull/576-]
> h2. New Decision:
> We will use a new strategy to retrieve session:
>  * try to retrieve session in the last known session index
>  * Store the last know session index in memory, update it if necessary if 
> session save request return a new session index (means a rollover happened)
>  * revert merged PR: https://github.com/apache/unomi/pull/576
> Disclaimer: We are aware of the fact that sessions may be reset in case they 
> are still alive while a rollover happen.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to