Implement idempotency TTL and enhance world stats collection
This commit is contained in:
@@ -14,8 +14,6 @@
|
||||
-- path) and read via showoptions, neither of which goes through the
|
||||
-- tokenizer, so they carry raw JSON unmolested.
|
||||
|
||||
-- TODO: does output still base64 encode? otherwise the API is weird (base64 json in, json out)
|
||||
|
||||
RDB_Base64 = {}
|
||||
|
||||
local ALPHABET = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"
|
||||
|
||||
@@ -24,6 +24,15 @@ RDB_Constants.MAX_PAYLOAD_BYTES = 4096
|
||||
RDB_Constants.OPTION_MAX_LENGTH = 8192
|
||||
RDB_Constants.POLL_EVERY_TICKS = 30
|
||||
|
||||
-- How long a request id's cached response is replayed for on retry before
|
||||
-- it's treated as expired and the op runs again. Deliberately short: a
|
||||
-- client that reuses a fixed id for routine polling (e.g. "ws-poll" every
|
||||
-- few minutes) should get a fresh answer each time, not the first-ever
|
||||
-- response forever. A count-based cap alone (MAX_ENTRIES in
|
||||
-- RDB_Idempotency) doesn't help here, it only evicts under high request
|
||||
-- volume, never under low-and-slow polling, which is exactly this case.
|
||||
RDB_Constants.IDEMPOTENCY_TTL_MS = 60 * 1000
|
||||
|
||||
RDB_Constants.ERROR_CODES = {
|
||||
SCHEMA_ERROR = "SCHEMA_ERROR",
|
||||
PAYLOAD_TOO_LARGE = "PAYLOAD_TOO_LARGE",
|
||||
|
||||
Reference in New Issue
Block a user