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

Add 20s delay into Run like crazy for the search scripts #228

Open
sergefedorow opened this issue Oct 2, 2024 · 1 comment
Open

Add 20s delay into Run like crazy for the search scripts #228

sergefedorow opened this issue Oct 2, 2024 · 1 comment
Assignees

Comments

@sergefedorow
Copy link

ENHANCEMENT in Run as crazy

I have an inconvenience with 'Run like crazy' when my script uses search. The default solr cron works every 15 seconds. So, if script updates the node it should wait more then 15 seconds to get updated data in the search. But, the javascript console have maximum 10 seconds in continuously run. Please add 20 seconds option in the 'Run like crazy' function.

To do so, add this line:
<option value="20000">${msg("value.twentyseconds")}</option>
before this one ootbee-jsconsole.get.html.ftl line 110

And update properties:
value.twentyseconds=continuously 20s delay
before the line ootbee-jsconsole.get.properties line71
e.t.c. for all languages.

@AFaust
Copy link
Contributor

AFaust commented Nov 20, 2024

Yesterday and today I ran into a similar issue with a bulk update script that relied on SOLR to retrieve the next batch of elements to update, and needed to manually trigger the next run / work with a second JavaScript Console + offset-based lookup to deal with the indexing delay. I would add both 20 and 30 seconds as options, as well as a user-provided delay input. This would be to account for the trigger being on a 15s schedule only by default, while indexing itself can take longer than the trigger interval, and depending on the timing of the end of the transaction and the last/current indexing run, it might even be that the indexing run which deals with the data that was just changed is actually the one after the next (tracking has a built in + configurable "lag" when looking for committed transactions). There could also be post-commit logic that an admin might want to account for, or they might simply want to space out their bulk operations a bit. Having options up to 30s (common delays) with an additional manual value input (custom delay) provides all the flexibility.

@AFaust AFaust self-assigned this Nov 20, 2024
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

No branches or pull requests

2 participants