BlackSpigot

Guide Slow Java plugin commands: separate network work from world changes

  • Thread starter Thread starter BlackSpigot Guides
  • Start date Start date
B

BlackSpigot Guides

Guest
A command that waits for a web request can make the whole server feel slow if the wait happens on its main thread.

Prove where the time goes
Reproduce the slow command on a test server. Capture a profile during the delay and identify whether the expensive work is HTTP, database access, file access, computation or world changes. Keep the baseline result. Do not move the whole handler to another thread without examining what it touches.

Split the operation into three stages
  • Collect the small amount of required state on the appropriate server thread. Validate the player's permission and input.
  • Perform suitable blocking I/O away from that thread, with a timeout and a bounded number of pending requests. Return plain result data.
  • Apply world or player changes through the scheduler appropriate to the server platform. Recheck that the player and target still exist and that the result is still relevant.
Large parts of the Bukkit API are unsafe from asynchronous tasks. Paper and Folia also have different scheduling requirements; choose the documented API for the platform you support.

Test failure, not just success
Try a slow response, failed response, duplicate command, player disconnect and plugin shutdown. Give the player a clear pending/result message. Keep requests from piling up if the remote service is unavailable, and avoid logging private response data.

Compare the same command and workload after the change. Share the small relevant handler and profile when requesting help; include the platform and versions.

Scheduling reference
 
Top