Use of singleton SyncHttpScheduler limits concurrency of requestToken calls

Calls to requestToken are sync in the SDK, and use a singleton executor in the SyncHttpScheduler. This means that requests will queue behind each other.

If you have 50 threads creating tokens, the executor can only do 1 thread worth of throughput.
Also related, adding more threads creating tokens means that all threads end up taking longer (not just the later threads taking linearly longer).

Token id: 12 with time since start 5123ms
Token id: 4 with time since start 5122ms
Token id: 14 with time since start 5122ms
Token id: 26 with time since start 5122ms
Token id: 39 with time since start 5121ms
Token id: 16 with time since start 5100ms
Token id: 1 with time since start 5124ms
Token id: 7 with time since start 5100ms
Token id: 18 with time since start 5123ms
Token id: 30 with time since start 5112ms

ably-java/lib/src/main/java/io/ably/lib/rest/Auth.java

Lines 850 to 851 in b2e6b22

    
           String tokenPath = "/keys/" + signedTokenRequest.keyName + "/requestToken"; 
        
           return HttpHelpers.postSync(ably.http, tokenPath, null, null, new HttpUtils.JsonRequestBody(signedTokenRequest.asJsonElement().toString()), new HttpCore.ResponseHandler<TokenDetails>() {

ably-java/lib/src/main/java/io/ably/lib/http/SyncHttpScheduler.java

Line 8 in b2e6b22

public class SyncHttpScheduler extends HttpScheduler {

┆Issue is synchronized with this Jira Task by Unito

@zknill let me check on this and get back to you

Can you provide some information for further clarification

What version of ably-java are you using? Does this problem started to happen recently?
Are you using SDK at server side ( spring boot ) or client side?
Did you try avoiding singleton to request token from ably?
What type of auth related clientOptions are you passing while creating AblyRest instance?

As per internal discussion =>

Recommendation is to use createTokenRequest method while providing ABLY_KEY in the clientOptions.
Because, it is mainly used for generating tokens for other clients to authenticate.
requestToken method is intended to self-authenticate the client. So, it makes sense for it to follow single thread executer

2. requestToken method is intended to self-authenticate the client. So, it makes sense for it to follow single thread executer

That's not always true. It's legitimate, although not recommended, for a server to generate tokens and forward them to clients, in which case the server will be generating tokens at a high rate.

I thought only server is recommended to have access for ROOT ABLY_KEY. So only server can issue user tokens with right privileges based on given business requirement.
Since use of ABLY_KEY at client side is not recommended, clients can't generate tokens on their own : (

Server can also use requestToken to generate client tokens when right API_KEY is provided. This again uses createTokenRequest method internally =>

ably-java/lib/src/main/java/io/ably/lib/rest/Auth.java

Line 845 in b2e6b22

signedTokenRequest = createTokenRequest(params, tokenOptions);

In such a case, there shouldn't be an issue with generating tokens in multithreading environment.

	String tokenPath = "/keys/" + signedTokenRequest.keyName + "/requestToken";
	return HttpHelpers.postSync(ably.http, tokenPath, null, null, new HttpUtils.JsonRequestBody(signedTokenRequest.asJsonElement().toString()), new HttpCore.ResponseHandler<TokenDetails>() {