-
Notifications
You must be signed in to change notification settings - Fork 126
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
base: master
Are you sure you want to change the base?
Conversation
…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.
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)); |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Jira URL
https://jira.xwiki.org/browse/XCOMMONS-3330
Changes
Description
Clarifications
Screenshots & Video
No UI changes.
Executed Tests
Expected merging strategy