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
- 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
@zknill let me check on this and get back to you
Can you provide some information for further clarification
- What version of
ably-javaare 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
AblyRestinstance?
As per internal discussion =>
-
Recommendation is to use
createTokenRequestmethod while providingABLY_KEYin the clientOptions. Because, it is mainly used for generating tokens for other clients to authenticate. -
requestTokenmethod is intended to self-authenticate the client. So, it makes sense for it to follow single thread executer
2.
requestTokenmethod 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 => 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.