You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As NServiceBus uses different CosmosDB operations depending on the user's code and configuration (e.g. whether Sagas, Outbox or both are used), it's not clearly visible what amount RUs need to be provisioned for the CosmosDB. Given the user has little insights into the actual operations used by the persistence, it's not possible to calculate the needs of the persistence from a user perspective.
Ideally, there is some guidance that helps understand the rough needs of RUs, e.g. per message being processed, depending on activated features that help provision a close enough RU capacity that is not too expensive but greatly reduces the risk of running into throttling. This is especially valuable in cases where this might prevent duplicates being created due to the Outbox running into request throttling.
Triage
This triage checklist should be filled in by a staff member from Particular Software.
Yes / No
Triage criteria
The expected effort to code and document the enhancement is less than 8 hours.
A reviewer can approve any changes in less than 1 hour.
The solution is obvious and does not require analysis by a task force.
The issue is NOT blocking the customer from using the Preview in production.
The issue is blocking the user from using the Preview in production.
There's evidence solving the problem will benefit multiple users.
The text was updated successfully, but these errors were encountered:
As NServiceBus uses different CosmosDB operations depending on the user's code and configuration (e.g. whether Sagas, Outbox or both are used), it's not clearly visible what amount RUs need to be provisioned for the CosmosDB. Given the user has little insights into the actual operations used by the persistence, it's not possible to calculate the needs of the persistence from a user perspective.
Ideally, there is some guidance that helps understand the rough needs of RUs, e.g. per message being processed, depending on activated features that help provision a close enough RU capacity that is not too expensive but greatly reduces the risk of running into throttling. This is especially valuable in cases where this might prevent duplicates being created due to the Outbox running into request throttling.
Triage
This triage checklist should be filled in by a staff member from Particular Software.
The text was updated successfully, but these errors were encountered: