Recompute current values of JMAP upload

hungphan227 commented 1 year ago

original ticket: https://github.com/linagora/james-project/issues/4816

WHY

to implement a webadmin API that admin can use to recompute current values of JMAP upload Cassandra counters are bad, and easy to go out of sync (Consistency Level ONE + non idempotent thus not retried if you ask). Hence we need a way to recompute quota as we know they would eventually go out of sync...

HOW

add a new field as a query para of the current Recompute Current Quota api: quotaComponent. The value could be mailbox, sieve, jmapUploads.
add field quotaComponent to the class RunningOptions of RecomputeCurrentQuotasService
create CurrentUploadUsageCalculator in server/data/data-jmap/src/main/java/org/apache/james/jmap/api/upload and use it in RecomputeCurrentQuotasService to recompute current jmapupload quota
if user do not specify quotaComponent in the http request, run all calculators. Otherwise run specific calculator.

DOD: integration test

quantranhong1999 commented 1 year ago

Normally we should write the grooming ticket in the form:

WHY? -> Why do we need to do this ticket
HOW? -> Basic proposal regarding how to do this ticket. A vague design would lead to much more time for code changing while implementation.
Definition Of Done -> How could we consider this ticket done?

And sometimes even with Notes, Side effects need to pay attention to...

An example: https://github.com/linagora/tmail-backend/issues/601

e.g here I think we should propose the JMAP Upload recompute Webadmin API with curl example.

hungphan227 commented 1 year ago

This is just a task from a ticket. I have already put reference to the original ticket in the description. The detail is presented in the original ticket.

chibenwa commented 1 year ago

How does this differ from https://james.apache.org/server/manage-webadmin.html#Recomputing_current_quotas_for_users ?

Maybe we can find a way to plug new operations in the existing task in a very modular fashion (interface, multi-binder)...

WDYT ?

WHY -> to implement a webadmin API that admin can use to recompute current values of JMAP upload

Not detailed enough. Cassandra counters are bad, and easy to go out of sync (Consistency Level ONE + non idempotent thus not retried if you ask). Hence we need a way to recompute quota as we know they would eventually go out of sync...

hungphan227 commented 1 year ago

@chibenwa @Arsnael I propose new solution:

add a new field to the request body of the current Recompute Current Quota api: quotaComponent. The value could be mailbox, sieve, jmapUploads.
add field quotaComponent to the class Context of RecomputeCurrentQuotasService and move the whole class to RecomputeCurrentQuotasTask
create new class RecomputeJmapUploadCurrentValue
depend on the value of quotaComponent, we will run either RecomputeCurrentQuotasService of RecomputeJmapUploadCurrentValue

Arsnael commented 1 year ago

Why not as a query parameter instead? with default value if omitted to run the current one?

For retro compatibility... and so I don't have to run around modifying potential cronjobs we have on our different environments with tmail regarding this :)

chibenwa commented 1 year ago

Why not as a query parameter instead? with default value if omitted to run the current one?

+1

And default value: run all. As a user I might not need to know all kind of quota maintained by James.

hungphan227 commented 1 year ago

I have updated the description

hungphan227 commented 1 year ago

draft PR https://github.com/apache/james-project/pull/1707

hungphan227 commented 1 year ago

PR https://github.com/apache/james-project/pull/1707

linagora / james-project

Recompute current values of JMAP upload #4833