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

Harvester / Add property to turn off scheduling #7217

Closed
wants to merge 7 commits into from

Conversation

fxprunayre
Copy link
Member

Related to #6990

When running in a scaled environment, user may want to only have one instance taking care of scheduled harvesting tasks. Adding a config property to turn it off/on using -Dharvester.scheduler.enabled=false. All instances can run a manually triggered harvesting task.

If set, the config property is also available in the admin > info panel

image

Also improve:

  • do not fail to startup if invalid scheduled config in database
  • improve error message while failing to update an harvester config

@sonarcloud
Copy link

sonarcloud bot commented Jul 13, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

0.0% 0.0% Coverage
0.0% 0.0% Duplication

idea Catch issues before they fail your Quality Gate with our IDE extension sonarlint SonarLint

Copy link
Member

@josegar74 josegar74 left a comment

Choose a reason for hiding this comment

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

Tested with 1 node and works as expected. Check the comments about multiple nodes support in the future.

label: "systemInformation"
},
{
key: "env"
Copy link
Member

Choose a reason for hiding this comment

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

The final goal for this I guess is to have multiple instances 1 with the scheduler enabled and the others disabled.

I'm not sure how useful is to display this information in such scenario as depending on the instance accessed the value displayed will be different.

Also this kind of stuff raises some questions, for example what happens in the node with the scheduler enabled fails? Should be implemented in a future pull request some mechanism so other node picks up the scheduler, using JMS messages or similar?

Copy link
Member Author

Choose a reason for hiding this comment

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

The final goal for this I guess is to have multiple instances 1 with the scheduler enabled and the others disabled.

Yes.

I'm not sure how useful is to display this information in such scenario as depending on the instance accessed the value displayed will be different.

Sure, but at least if you access the instance with scheduler on by its url you can check that the settings is properly enabled.

Also this kind of stuff raises some questions, for example what happens in the node with the scheduler enabled fails? Should be implemented in a future pull request some mechanism so other node picks up the scheduler, using JMS messages or similar?

We are not here yet, but yes this is some further improvement we could plan.

@fxprunayre
Copy link
Member Author

In #7337

@fxprunayre fxprunayre closed this Sep 13, 2023
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.

3 participants