[
https://issues.apache.org/jira/browse/UNOMI-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Serge Huber updated UNOMI-1000:
-------------------------------
Description:
h3. Summary
Unomi runs several tasks in the background. In 4.0, some of them only see the
data of the internal "system" tenant. They skip every real tenant, including
"default", where migrated data goes:
* Purge of old profiles, sessions and events. The purge settings have no
effect, so data keeps growing.
* Daily update of segments and scorings that use relative dates, such as
"visited in the last 7 days". Profiles never leave these segments.
* Recurring imports and exports. After a restart they are not scheduled again
until someone saves their configuration.
* Refresh of rule statistics.
Other tasks, such as the rule refresh and tenant usage, already go through
every tenant.
The goal of this ticket is that these tasks run for every tenant.
h3. Ways to explore
* Run each task once per tenant, with that tenant's context, as the rule
refresh already does. Restore the previous context after each tenant so nothing
carries over.
* Do not fix this by letting the system context read all tenants at once. That
would change how data is kept apart for every caller.
* Recurring imports and exports must run with their own tenant, and keep the
file location limits added by UNOMI-973.
h3. How to test
Manual check: in the "default" tenant, check that a profile older than the
purge setting is removed, that a profile leaves a "last 7 days" segment once it
is too old, and that a recurring import runs again after a restart.
Automated tests to add, each with at least two tenants besides "system". Each
must fail on the 4.0.0 release candidate and pass once the fix is in:
* Profile purge: old profiles, sessions and events are removed in every tenant,
and recent ones are kept.
* Segment and scoring update: a profile in a relative-date segment of a tenant
leaves it once the date has passed.
* Rule statistics: statistics are refreshed for the rules of every tenant.
* Imports and exports: after a restart of the router, the recurring
configurations of every tenant are scheduled again. The import writes into its
own tenant, and the file location limits still apply.
* Separation: a task run for one tenant never changes another tenant's data,
and the context is the same before and after the task. This guards against data
leaking between tenants.
* A check that the persistence filter for the system context is unchanged, so
this fix cannot be done by widening it.
was:
h3. Summary
Unomi runs several tasks in the background. In 4.0, some of them only see the
data of the internal "system" tenant. They skip every real tenant, including
"default", where migrated data goes:
* Purge of old profiles, sessions and events. The purge settings have no
effect, so data keeps growing.
* Daily update of segments and scorings that use relative dates, such as
"visited in the last 7 days". Profiles never leave these segments.
* Recurring imports and exports. After a restart they are not scheduled again
until someone saves their configuration.
* Refresh of rule statistics.
Other tasks, such as the rule refresh and tenant usage, already go through
every tenant.
The goal of this ticket is that these tasks run for every tenant.
h3. Ways to explore
* Run each task once per tenant, with that tenant's context, as the rule
refresh already does. Restore the previous context after each tenant so nothing
carries over.
* Do not fix this by letting the system context read all tenants at once. That
would change how data is kept apart for every caller.
* Recurring imports and exports must run with their own tenant, and keep the
file location limits added by UNOMI-973.
h3. How to test
In the "default" tenant, check that:
* a profile older than the purge setting is removed,
* a profile leaves a "last 7 days" segment once it is too old,
* a recurring import runs again after a restart.
> Background tasks only process the internal "system" tenant
> ----------------------------------------------------------
>
> Key: UNOMI-1000
> URL: https://issues.apache.org/jira/browse/UNOMI-1000
> Project: Apache Unomi
> Issue Type: Bug
> Affects Versions: unomi-4.0.0
> Reporter: Serge Huber
> Priority: Blocker
> Fix For: unomi-4.0.0
>
>
> h3. Summary
> Unomi runs several tasks in the background. In 4.0, some of them only see the
> data of the internal "system" tenant. They skip every real tenant, including
> "default", where migrated data goes:
> * Purge of old profiles, sessions and events. The purge settings have no
> effect, so data keeps growing.
> * Daily update of segments and scorings that use relative dates, such as
> "visited in the last 7 days". Profiles never leave these segments.
> * Recurring imports and exports. After a restart they are not scheduled again
> until someone saves their configuration.
> * Refresh of rule statistics.
> Other tasks, such as the rule refresh and tenant usage, already go through
> every tenant.
> The goal of this ticket is that these tasks run for every tenant.
> h3. Ways to explore
> * Run each task once per tenant, with that tenant's context, as the rule
> refresh already does. Restore the previous context after each tenant so
> nothing carries over.
> * Do not fix this by letting the system context read all tenants at once.
> That would change how data is kept apart for every caller.
> * Recurring imports and exports must run with their own tenant, and keep the
> file location limits added by UNOMI-973.
> h3. How to test
> Manual check: in the "default" tenant, check that a profile older than the
> purge setting is removed, that a profile leaves a "last 7 days" segment once
> it is too old, and that a recurring import runs again after a restart.
> Automated tests to add, each with at least two tenants besides "system". Each
> must fail on the 4.0.0 release candidate and pass once the fix is in:
> * Profile purge: old profiles, sessions and events are removed in every
> tenant, and recent ones are kept.
> * Segment and scoring update: a profile in a relative-date segment of a
> tenant leaves it once the date has passed.
> * Rule statistics: statistics are refreshed for the rules of every tenant.
> * Imports and exports: after a restart of the router, the recurring
> configurations of every tenant are scheduled again. The import writes into
> its own tenant, and the file location limits still apply.
> * Separation: a task run for one tenant never changes another tenant's data,
> and the context is the same before and after the task. This guards against
> data leaking between tenants.
> * A check that the persistence filter for the system context is unchanged, so
> this fix cannot be done by widening it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
