Concurrent JS5 Implementation #36
Description
Our current JS5 implementation relies on one worker thread to respond to all the JS5 requests. While the work itself is light-weight and should never cause problems, we do have the issue of synchronization being used when passing information from Netty threads to the JS5 service. This synchronization is very short-lived and shouldn't cause issues, but it probably does cost us some performance. For reference, many of the so-called concurrent data structures in Java actually rely on short-lived synchronization, which isn't inherently bad, but it can cost us some performance.
As such, we should look into options of doing JS5 completely concurrently, without ever blocking Netty in that. This will be complicated to implement, at least in a manner where everyone is served equally as our current system providers, but it could result in a little better overall performance in some extreme edge cases. This new system would be marked as experimental and would be opt-in. The old system should always remain available, even once this new system is no longer experimental, should people prefer this style, as it will likely still remain more fair than a concurrent one.