Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IGNITE-14625 #9037

Merged
merged 12 commits into from Apr 30, 2021
Merged

IGNITE-14625 #9037

merged 12 commits into from Apr 30, 2021

Conversation

tkalkirill
Copy link
Contributor

Thank you for submitting the pull request to the Apache Ignite.

In order to streamline the review of the contribution
we ask you to ensure the following steps have been taken:

The Contribution Checklist

  • There is a single JIRA ticket related to the pull request.
  • The web-link to the pull request is attached to the JIRA ticket.
  • The JIRA ticket has the Patch Available state.
  • The pull request body describes changes that have been made.
    The description explains WHAT and WHY was made instead of HOW.
  • The pull request title is treated as the final commit message.
    The following pattern must be used: IGNITE-XXXX Change summary where XXXX - number of JIRA issue.
  • A reviewer has been mentioned through the JIRA comments
    (see the Maintainers list)
  • The pull request has been checked by the Teamcity Bot and
    the green visa attached to the JIRA ticket (see TC.Bot: Check PR)

Notes

If you need any help, please email dev@ignite.apache.org or ask anу advice on http://asf.slack.com #ignite channel.

SimpleTask t = new SimpleTask("t");
IgniteInternalFuture<Void> execAsyncFut = execAsync(n, t, false);

t.onExecFut.get(getTestTimeout());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't getTestTimeout() too big for this case? I suggest to replace it with another, small timeout.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this timeout will show that something is wrong.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean, if something goes wrong, test will fail faster.

Comment on lines 118 to 150
@Override public IgniteInternalFuture<DurableBackgroundTaskResult> executeAsync(GridKernalContext ctx) {
log = ctx.log(this.getClass());

assert worker == null;

GridFutureAdapter<DurableBackgroundTaskResult> fut = new GridFutureAdapter<>();

worker = new GridWorker(
ctx.igniteInstanceName(),
"async-durable-background-task-executor-" + name(),
log
) {
/** {@inheritDoc} */
@Override protected void body() throws InterruptedException, IgniteInterruptedCheckedException {
try {
execute(ctx);

worker = null;

fut.onDone(DurableBackgroundTaskResult.complete(null));
}
catch (Throwable t) {
worker = null;

fut.onDone(DurableBackgroundTaskResult.restart(t));
}
}
};

new IgniteThread(worker).start();

return fut;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems that this method could be common for any tasks, shouldn't we move it to DurableBackgroundTasksProcessor?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be done as needed.

log.info("Executing durable background task: " + task.shortName());
/** {@inheritDoc} */
@Override public void onMarkCheckpointBegin(Context ctx) {
for (Iterator<Entry<String, DurableBackgroundTaskState>> it = tasks.entrySet().iterator(); it.hasNext(); ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any locks here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's not scary if part of the task is completed a little later, since then they will definitely be deleted at the next checkpoint.

@ibessonov ibessonov merged commit 598e97b into apache:master Apr 30, 2021
xintrian pushed a commit to xintrian/ignite that referenced this pull request May 27, 2022
… issue when checkpointer could preemptively delete completed task, potentially causing leaks. (apache#9037)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants