Use of singleton SyncHttpScheduler limits concurrency of requestToken calls

[zknill]

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

• https://github.com/ably/ably-java/blob/b2e6b222a09b0698793a2c1a2c851fad384564cb/lib/src/main/java/io/ably/lib/rest/Auth.java#L850-L851
• https://github.com/ably/ably-java/blob/b2e6b222a09b0698793a2c1a2c851fad384564cb/lib/src/main/java/io/ably/lib/http/SyncHttpScheduler.java#L8

┆Issue is synchronized with this Jira Task by Unito

[sacOO7]

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

[sacOO7]

Can you provide some information for further clarification

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

[sacOO7]

As per internal discussion =>

1. 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.

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

[paddybyers]

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.

[sacOO7]

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 : (

[sacOO7]

Server can also use requestToken to generate client tokens when right API_KEY is provided. This again uses createTokenRequest method internally => https://github.com/ably/ably-java/blob/b2e6b222a09b0698793a2c1a2c851fad384564cb/lib/src/main/java/io/ably/lib/rest/Auth.java#L845

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