-
Enhancement
-
Resolution: Unresolved
-
P3
-
None
-
None
-
None
It's common for bot runners to be bogged down with WorkItems, creating long latencies for users issuing commands or modifying PRs before Skara reacts. This is especially true when bots are restarted and they have to catch up on the complete state of every PR, or, as just happened during the jdk23 branching event, the PR bot triggered CheckWorkItems for every open PR right after the .jcheck/conf change was integrated into the master branch, which then severely delayed the subsequent /tag and /branch commands (30 to 40 minutes).
The BotRunner runs WorkItems in a ThreadpoolExecutor. This limits concurrency to the number of threads in the executor. To generate new WorkItems, each bot is periodically called for `getPeriodicItems`. To make these call at regular intervals, the we specifically use the subclass ScheduledThreadpoolExecutor for the executor.
To reduce the impact of massive scheduling of WorkItems triggered by certain events, such as startup, we need to introduce priority in the executor. WorkItems directly triggered by user input would get highest priority, WorkItems that are just periodically checking for updates would be lower, and WorkItems triggered by secondary events, such as startup, or .jcheck/conf updates, would get lowest. I believe this would dramatically improve latencies for user interactions.
Implementing this will be tricky due to the use of the ScheduledThreadpoolExecutor. It doesn't seem to support being extended. If we used a regular ThreadPoolExecutor, we could just instantiate it with a PriorityBlockingQueue and implement our own Comparator for priority. If we did this we would need to figure out some other solution for the periodically scheduled items. I'm not sure how to best solve this yet. The simplest solution is probably to use two separate executors, one for WorkItems and one for scheduled tasks. I think this would be fine.
The BotRunner runs WorkItems in a ThreadpoolExecutor. This limits concurrency to the number of threads in the executor. To generate new WorkItems, each bot is periodically called for `getPeriodicItems`. To make these call at regular intervals, the we specifically use the subclass ScheduledThreadpoolExecutor for the executor.
To reduce the impact of massive scheduling of WorkItems triggered by certain events, such as startup, we need to introduce priority in the executor. WorkItems directly triggered by user input would get highest priority, WorkItems that are just periodically checking for updates would be lower, and WorkItems triggered by secondary events, such as startup, or .jcheck/conf updates, would get lowest. I believe this would dramatically improve latencies for user interactions.
Implementing this will be tricky due to the use of the ScheduledThreadpoolExecutor. It doesn't seem to support being extended. If we used a regular ThreadPoolExecutor, we could just instantiate it with a PriorityBlockingQueue and implement our own Comparator for priority. If we did this we would need to figure out some other solution for the periodically scheduled items. I'm not sure how to best solve this yet. The simplest solution is probably to use two separate executors, one for WorkItems and one for scheduled tasks. I think this would be fine.