Highlights:
- Fix: hot reload of waf-rules now works as expected via
cache-rpc waf-reloadcommand - Bounded wait queue was implemented for RPC requests. Now when application starts, it can accept 2 additional parameters:
account-request-queue-size- number of client connections that can wait for available permits for getAccountInfoprogram-request-queue-size- number of connections that can wait for available permits for getProgramAccounts
Those two parameters complement the other two parametersaccount-request-limitandprogram-request-limitrespectively. What they do is, they can prevent new client requests, which cannot be served from cache, from trying to acquire available permits for their corresponding request type, and as such indirectly allow to control how many requests can be made to validator in short bursts. It basically works by forcing every request (not serviceable from cache) to get into queue (which has limited size), before even trying to acquire permit to make the actual request, if it doesn't succeed (due to queue being full), the response will be returned immediately to client with message explaining that there are too many requests of this type is being made. If request does succeed, it can go ahead and try to acquire a permit for making the request, and upon success it will move out of wait queue, so that other requests can also attempt to acquire a permit (by getting into queue). These parameters can be hot reloaded from config file, the same way thataccount-request-limitandprogram-request-limitcan, example config might look like this:
[rpc]
ignore_base58_limit = true
[rpc.request_limits]
account_info = 500
program_accounts = 15
[rpc.request_queue_size]
account_info = 1000 # default is set to value 2 ^ 19, effectively disabling any restrictions
program_accounts = 75 # default is set to value 2 ^ 18, effectively disabling any restrictions- Completely reworked subscription tracking (biggest change of release), here's the list of most notable updates:
- When getAccountInfo triggers subscription, account key starts being tracked in program cache, by means of the public key of account owner, it's done to transfer subscription management responsibility to owner program, when request for its owner will be made in future.
- If during subscription attempt for account, it's found that owner program already has cache entry and subscription, then no new account subscription is created, but account key is still added to the list of tracked keys of its owner.
- When getProgramAccouns gets cached, it unsubscribes from all tracked child accounts accounts without deleting them from cache.
- All accounts, which are being tracked by their owner, get served from cache, as long as parent has an active subscription, and do not create their own subscription, but resetting their ttl nonetheless.
- When getAccountInfo hits the cache it creates a purge task for itself, and when timer expires, it removes itself from tracked
accounts in its owner's cache entry, and tries to remove itself from accounts cache, succeeding only if no other getProgramAccounts request is tracking it. - When getAccountInfo misses the cache, while it's owner still having active subscription, the result is similar to case 5, it fetches account by RPC, puts it into accounts cache, starts tracking it in owner's cache entry, and doesn't create extra subscription for itself, while still making sure that it will be removed from cache when it's ttl ends.
- When getProgramAccounts cache entry expires, it will perform cleanup for all of its child accounts, except for those which had recent cache hits, in which case it will resubscribe for those before terminating its own subscription.
What's Changed
- Fixed waf rules reload by @bobs4462 in #219
- Implementation of bounded wait queue for rpc requests by @bobs4462 in #187
- Subsription tracking refactoring by @bobs4462 in #215
- Wait queue size for rpc requests was made optional by @bobs4462 in #222
- chore: bump version to 0.2.1 + remove mlua patch by @bobs4462 in #221
Full Changelog: 0.2.0...0.2.1