[
https://issues.apache.org/jira/browse/UNOMI-1002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1002:
-------------------------------
Description:
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.
was:
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
Run many parallel context.json requests in compatibility mode. They should not
be slower than in normal mode. Run all the tests.
> 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
> Priority: Critical
> Fix For: unomi-4.0.0
>
>
> 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)
