Skip to content

XCOMMONS-3330: Job groups with several threads may not return a current job #1329

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

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

michitux
Copy link
Contributor

@michitux michitux commented May 9, 2025

Jira URL

https://jira.xwiki.org/browse/XCOMMONS-3330

Changes

Description

  • Store several current jobs.
  • Add a new possibility to return all running jobs of a job group.
  • Deprecate the old method that returns just a single running job.
  • Clean up empty entries in groupedJobs.
  • Some code cleanup.

Clarifications

  • This needs more testing, in particular in automated tests.

Screenshots & Video

No UI changes.

Executed Tests

mvn clean install -Pintegration-tests,docker,legacy,quality -pl :xwiki-commons-job-api,:xwiki-commons-job-default

Expected merging strategy

  • Prefers squash: Yes
  • Backport on branches:
    • Not sure, we could decide to backport this.

…nt job

* Store several current jobs.
* Add a new possibility to return all running jobs of a job group.
* Deprecate the old method that returns just a single running job.
* Clean up empty entries in groupedJobs.
* Some code cleanup.
@michitux michitux self-assigned this May 9, 2025
return executor != null ? executor.currentJob : null;
if (executor != null) {
// Return an unmodifiable copy of the set of currently running jobs.
return Collections.unmodifiableCollection(new ArrayList<>(executor.currentJobs));
Copy link
Member

Choose a reason for hiding this comment

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

It's not clear to me why you create an ArrayList. Isn't Collections.unmodifiableCollection enough to make the set readonly ?

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 want to avoid that the collection updates when jobs are started or stopped. I would expect that we expose this method in a script service and I don't want to let the author of a Velocity script deal with the fact that directly after isEmpty() returns false, there might not be any elements anymore in the collection.

We could also let this return a List, this might make things more explicit what to expect in terms of the different operations?

Copy link
Member

Choose a reason for hiding this comment

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

I want to avoid that the collection updates when jobs are started or stopped.

Very good point indeed.

We could also let this return a List, this might make things more explicit what to expect in terms of the different operations?

Why not.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. I also found and fixed some issues in the implementations for constructing the list both in the default and in the actual implementation.

…nt job

* Change the API to return a List for the current jobs.
* Fix not returning a list with a null value in the default
  implementation.
* Fix synchronization on the set for iterating over it.
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.

2 participants