[
https://issues.apache.org/jira/browse/UNOMI-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18125742#comment-18125742
]
Serge Huber commented on UNOMI-1002:
------------------------------------
Pull request: https://github.com/apache/unomi/pull/915
{{getOrCreateTenant}} now caches the tenant after the first load/create, takes
a lock only on a cache miss (so concurrent first requests still create exactly
once), and invalidates on save/delete/API-key updates. Compatibility mode
public requests no longer serialize on every hit.
> In compatibility mode, all public requests wait on each other
> -------------------------------------------------------------
>
> Key: UNOMI-1002
> URL: https://issues.apache.org/jira/browse/UNOMI-1002
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Assignee: Serge Huber
> Priority: Critical
> Fix For: unomi-4.0.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Summary
> In single-tenant compatibility mode, every public request, such as
> context.json or the event collector, checks that the default tenant exists.
> This check runs one request at a time across the whole server, and it reads
> the tenant from the database each time. Under load, public requests queue
> behind each other.
> This came with UNOMI-980, which made the mode create its tenant on its own.
> Jonathan Sinovassin-Naïk has offered to propose a fix.
> The goal of this ticket is that public requests in compatibility mode do not
> wait on each other.
> h3. Ways to explore
> * Create the default tenant once, when the mode starts or on the first
> request, then read it from a cache.
> * Only take the lock when the tenant does not exist yet.
> * The tenant id stays fixed by the mode and is never taken from the request.
> * Refresh the cached tenant when it is updated or deleted.
> h3. How to test
> Manual check: run many parallel context.json requests in compatibility mode.
> They should not be slower than in normal mode.
> Automated tests to add:
> * A unit test that sends many public requests in compatibility mode and
> checks that the tenant is read from the database once, not once per request.
> * A concurrency test where many first requests arrive at the same time on an
> empty system: exactly one tenant is created, and every request succeeds.
> * A test that an update or deletion of the tenant is seen by the next request.
> * A test that no request header or parameter can change which tenant is
> created or used.
> * The existing compatibility mode tests for UNOMI-980 still pass.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
