Move Redis publishing off caller threads and reuse connections

[BenCodez]

Summary

• move RedisHandler.publishEnvelope(...) network work onto one ordered daemon publisher thread
• reuse Redis connections through a JedisPool instead of constructing/authenticating a fresh Jedis connection for every envelope
• bound the publisher queue at 1,024 messages and drop with debug logging rather than falling back to the caller thread
• drain the publisher for a bounded period during shutdown, then close the pool
• keep Redis subscription handling on its existing dedicated blocking connection/thread
• add regression coverage proving publishes return without waiting for transport I/O, execute off the caller thread, and preserve message order

Why

A Spark profile from VotingPlugin 7.1.2-SNAPSHOT showed backend presence publishing on the Bukkit server thread:

Server thread
└─ BungeeHandler
   └─ sendActivePresenceMessage
      └─ sendPresenceMessage
         └─ GlobalMessageHandler.sendMessage
            └─ RedisHandler.publishEnvelope
               ├─ new Jedis
               ├─ connect
               ├─ helloAndAuth
               └─ publish

Most of the sampled VotingPlugin server-thread time in that stack was Redis connection setup/authentication rather than the actual PUBLISH. Presence login/logout and snapshot responses can call this path from Bukkit tasks, so a slow Redis connection can block ticks for up to the configured connection/socket timeout.

publishEnvelope returns void, so callers do not consume a synchronous publish result. Serializing outbound publishes through one bounded worker preserves ordering while removing socket/connect/auth I/O from Bukkit and other caller threads.

Behavior

• publisher connection/authentication is amortized through the pool
• outbound messages remain ordered per RedisHandler instance
• queue saturation never executes Redis I/O on the caller thread
• shutdown stops accepting new publishes, allows queued messages a bounded drain window, then closes the publisher pool

Regression coverage

RedisHandlerTest blocks the transport operation intentionally and verifies that:

• publishEnvelope returns promptly while the first publish is still blocked
• transport work runs on a different thread from the caller
• two queued publishes execute on the same ordered worker
• publish order is preserved

Scope

This fixes the shared SimpleAPI Redis transport used by VotingPlugin/AdvancedCore rather than adding VotingPlugin-specific threading around the same synchronous transport.

AI disclosure: This pull request was created with assistance from ChatGPT and should receive normal maintainer review.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d7d3a5d15e

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".