[CBR-179] Bouncing and throttling#3431
Conversation
e300523 to
ae68910
Compare
a59ebf8 to
23aec43
Compare
|
Conflicts come from the split recently done between the legacy wallet and the new one. |
- Format message as JSend, include retry information - Use the API error mechanism so it can be caught more easily on client side - Add to sample, test
This function allows you to uniformly add an error handler to each endpoint of the WalletClient type. This will be used in an upcoming commit to provide the throttling retry logic.
This should prevent the failures from throttling to occur in integration testing until we can have file-level configuration of the integration test.
9b848b6 to
a4b14e8
Compare
|
Okay, I squashed a bunch of stuff together while rebasing and resolving conflicts. Maaaaaaan, that was something. We really need to work on our git practices 😢 ... Also, I've made one slight change instead of solving 18 times the same conflict. I've defined a higher abstraction -- | Natural transformation + mapping on a 'WalletClient'
natMapClient
:: (forall x. m x -> n x)
-> (forall x. n (Either ClientError x) -> n (Either ClientError x))
-> WalletClient m
-> WalletClient n
natMapClient phi f wc = WalletClient
{ getAddressIndexPaginated =
\x -> f . phi . getAddressIndexPaginated wc x
-- ... etc
-- | Run the given natural transformation over the 'WalletClient'.
hoistClient :: (forall x. m x -> n x) -> WalletClient m -> WalletClient n
hoistClient phi =
natMapClient phi id
-- | Generalize a @'WalletClient' 'IO'@ into a @('MonadIO' m) =>
-- 'WalletClient' m@.
liftClient :: MonadIO m => WalletClient IO -> WalletClient m
liftClient = hoistClient liftIO
mapClientErrors :: forall m. Monad m => ResponseErrorHandler m -> WalletClient m -> WalletClient m
mapClientErrors handler =
natMapClient id overError |
|
@disassembler @cleverca22 This can most probably be left as |
70665d7 to
3d2e22b
Compare
3d2e22b to
549e5be
Compare
|
🙄 👀 |
akegalj
left a comment
There was a problem hiding this comment.
Looks good to me.
I am a bit worried that the defaults are not right compared to V0 (althought its hard to tell because we didn't benchmark it)
| background process. | ||
|
|
||
| - #### Add bouncing and throttling to the API | ||
| Previously, exchanges could accidentally overload their wallet servers. We |
There was a problem hiding this comment.
there was a throttling in v0 per handler https://github.com/input-output-hk/cardano-sl/blob/develop/wallet/src/Pos/Wallet/Web/Methods/Payment.hs#L80
| # # Number of requests per throttling period. | ||
| # rate: 200 | ||
| # # Amount of microseconds in a throttling period. | ||
| # period: 1_000_000 |
There was a problem hiding this comment.
https://github.com/input-output-hk/cardano-sl/blob/develop/wallet/src/Pos/Wallet/Web/Methods/Payment.hs#L80 note that we have "throttled" 6 seconds here - which is 6 times more then here. I know new data layer is probably more optimized then the old one - but maybe we should measure or check why did we pick 6 in v0. I know it was due to sev1 performance problem
There was a problem hiding this comment.
Note that this is actually quite a bit faster -- we have rate requests per period microseconds, so 200 requests permitted per second in this configuration, across the board. It is disabled entirely by default.
More fine-grained throttling can easily be done at the handler level, I think.
There was a problem hiding this comment.
so 200 requests permitted per second in this configuration
yes - we just have to check eventually is our wallet layer up to the task. I am not sure have we run benchmarks on new wallet layer and compared it to the old one
| defaultThrottleSettings :: ThrottleSettings | ||
| defaultThrottleSettings = ThrottleSettings | ||
| { tsRate = 30 | ||
| , tsPeriod = 1000000 |
There was a problem hiding this comment.
06d8c0f to
7d541a4
Compare
|
@parsonsmatt |
|
@akegalj I merged because there are configuration changes that were nightmarish to deal with along with other work that's going on in the wallet. Target that PR against |
Description
This PR adds throttling capability to the Wallet API as well as the ability to load the configuration from the file.
Note: This requires the
configuration.yamlfile be modified to include thewalletsection. We should figure out how that affects clients.Linked issue
https://iohk.myjetbrains.com/youtrack/issue/CBR-179
Type of change
Developer checklist
Testing checklist
I have not added new tests for this feature. The sort of test we could implement to verify throttling works is to spam the server with a bunch of requests and verify that some of them are
429. However, the test-suite for the library already does this, so we'd be replicating the work.Existing tests already catch parsing the config format.
QA Steps
Screenshots (if available)