[
https://issues.apache.org/jira/browse/JAMES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Tellier updated JAMES-3779:
----------------------------------
Description:
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.
was:
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() {
// blah
}
}
{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.
> 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.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
