[
https://issues.apache.org/jira/browse/JAMES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier closed JAMES-3779.
---------------------------------
Resolution: Fixed
Done
> Tasks are doing seaky blocking calls
> ------------------------------------
>
> Key: JAMES-3779
> URL: https://issues.apache.org/jira/browse/JAMES-3779
> Project: James Server
> Issue Type: Bug
> Components: cassandra, task
> Reporter: Benoit Tellier
> Priority: Major
>
> h2. What is the problem
> h4. Blocking call into Task constructor
> Some of our tasks do blocking calls into their constructors.
> Example:
> {code:java}
> public ClearMailRepositoryTask(List<MailRepository> mailRepositories,
> MailRepositoryPath path) {
> this.mailRepositories = mailRepositories;
> this.mailRepositoryPath = path;
> this.initialCount = getRemainingSize(); // blocking
> }
> {code}
> Logic into constructor:
> - Is clearly an anti-pattern
> - This stuff get's deserialized so we should be really careful with what
> get's into the constructor
> - We don't expect blocking calls when deserializing
> We should get rid of all those blocking calls into constructors.
> h4. Blocking calls when generating task details
> We might need to do backend calls when generating task details, eg querying
> the DB to know how much records remains.
> The issue here is that those blocking calls are 'hidden'. We should enable
> tasks to expose a publisher for getting their details, allowing to wrap "on
> demand" their details.
> {code:java}
> interface Task {
> default Optional<TaskExecutionDetails.AdditionalInformation> details() {
> return Optional.empty();
> }
> default Publisher<TaskExecutionDetails.AdditionalInformation>
> detailsReactive() {
> return Mono.fromCallable(() -> details)
> .handle(ReactorUtils::publishIfPresent);
> }
> }
> {code}
> This would enable:
> - To preserve the non blocking chain
> - To wrap blocking calls only where needed.
> h3. Why is this needed?
> The Cassandra driver 4 work highlighted the limitation of our task system. We
> got away with quick fixes but a little redesign will get this sorted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
