Skip to content

Queueing System Expansion:#277

Closed
PoseidonsCave wants to merge 1 commit into
rfresh2:1.21.4from
PoseidonsCave:1.21.4-queueing-system
Closed

Queueing System Expansion:#277
PoseidonsCave wants to merge 1 commit into
rfresh2:1.21.4from
PoseidonsCave:1.21.4-queueing-system

Conversation

@PoseidonsCave

Copy link
Copy Markdown
  • Added CommandQueue class to manage command execution order and timing.
  • Updated CommandManager to utilize CommandQueue for better command handling.
  • Modified DiscordBot to integrate with CommandQueue for improved performance.
  • Enhanced CommandAction to support queued command execution.
  • Added CommandQueueTest to ensure proper functionality of the CommandQueue system.

* Added CommandQueue class to manage command execution order and timing.
* Updated CommandManager to utilize CommandQueue for better command handling.
* Modified DiscordBot to integrate with CommandQueue for improved performance.
* Enhanced CommandAction to support queued command execution.
* Added CommandQueueTest to ensure proper functionality of the CommandQueue system.
@rfresh2

rfresh2 commented Apr 5, 2026

Copy link
Copy Markdown
Owner

not clear to me what problem you are trying to solve

but i have the feeling this is overcomplicated

@PoseidonsCave

Copy link
Copy Markdown
Author

Basically trying to solve the problem of multiple discord commands being entered at once. The idea is to create a pipeline for if two or more commands are entered simultaneously (whether they are part of a core zenith function, or if the command is for an external plugin. That way it can be managed w/ grace rather than the command being dropped

@rfresh2

rfresh2 commented Apr 5, 2026

Copy link
Copy Markdown
Owner

the command executor can be made single threaded

here:

public void execute(final CommandContext context, final ParseResults<CommandContext> parseResults) {

just add @Locked or synchronized

the queue then is implicit as other threads will have to wait until freed

@PoseidonsCave

Copy link
Copy Markdown
Author

i mean yeah, but if f multiple plugins can issue commands concurrently, then without a central mechanism, plugin behavior becomes timing-dependent.

a plugin issuing commands rapidly could potentially starve or interleave commands from another plugin. A queue provides a fair and deterministic dispatch point between plugins and command execution. e.g if someone is making a pearl request + then initiating an autotrader command

@rfresh2

rfresh2 commented Apr 5, 2026

Copy link
Copy Markdown
Owner

locking is a central mechanism. same as your queue. both are queues actually.

and the issues you are bringing up simply don't happen in actual use

there's no reason for plugins or anyone else to submit enough commands per second. real use timescales are far larger than you are imagining

@PoseidonsCave

Copy link
Copy Markdown
Author

ah I see, makes sense, i'll have to mess around with it more. thank you!

@PoseidonsCave PoseidonsCave deleted the 1.21.4-queueing-system branch April 5, 2026 23:20
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