-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(request-aware-table) add request aware table #11017
Conversation
35086ad
to
95706cd
Compare
What is request aware table in comparison to |
I wondered that myself @bungle, thanks for bringing it up. The main difference is that this table can detect race conditions and throw an error if they happen, instead of using separate scopes for each request to prevent them. However, if the performance impact of accessing this table compared to using the context is not significant, we could solve the same problem just as in this PR, using I'd be curious to hear @dndx 's opinion as well |
0db9d43
to
7530d1d
Compare
717117e
to
09d2481
Compare
09d2481
to
4bf980a
Compare
85553b9
to
862d76d
Compare
6f69d98
to
d83b6d3
Compare
@dndx could you take a look at this PR again? thx |
ddf396f
to
fede892
Compare
kong/tools/request_aware_table.lua
Outdated
|
||
-- Check if access is allowed for table, based on the request ID | ||
local function enforce_sequential_access(table) | ||
if next(table.__data) == nil or not get_request() then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the empty __data
table check? I thought just checking __allowed_request_id
below is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the empty __data
check is used to reset __allowed_request_id
when the table is cleared. If there is no data it means the table was emptied. I removed it now that I reintroduced the :clear()
method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@samugi I see. :clear
would be a safer approach and I think we should keep that. It also makes the clearing intention more explicit.
end | ||
|
||
return { | ||
new = new, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need a :clear
method as well? How to clear __data
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I initially included a :clear
method but that would mean the table has a different interface when in debug_mode
compared to when it is not (in which case we just return a regular table).
One alternative I implemented now is to always include the :clear
method for request_aware_table, the difference being that in non debug_mode
the metatable with concurrency checks is not applied, wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you are saying. We can do this:
With debug mode on:
Use the proxy and metatable.
With debug mode on:
Use a different metatable _mt_direct
, no proxy in this case. Define the :clear
on this metatable only, not table instance.
This avoids you having to hack the "clear" method on the table each time, and prevents it being accidentally cleared by the user using table.clear
manually.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, I like that.
e5e3d6a
to
385dffb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usage in a plugin
[cache_key] = <integer> | ||
--]] | ||
} | ||
local cur_usage = request_aware_table.new() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we might want to preallocate some nrec, what could be a good value?
385dffb
to
85f093a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! A clever idea and neat implementation 🚀
I left a few code style comments but it's entirely up to you. I'm happy with the way the code looks right now 👏
spec/fixtures/custom_plugins/kong/plugins/request-aware-table/handler.lua
Outdated
Show resolved
Hide resolved
spec/fixtures/custom_plugins/kong/plugins/request-aware-table/handler.lua
Show resolved
Hide resolved
afe83aa
to
2901f39
Compare
add a request-aware table able to detect accesses from different requests.
* refactor * only use static log level to turn concurrency checks on or off * use single metatable, keep data and request_id in the instance * use table.new -style initialization * reintroduce :clear() method Co-authored-by: Datong Sun <[email protected]>
* small refactors here and there
546a7a3
to
e17992f
Compare
Summary
Add a request-aware table able to detect accesses from different requests.
Checklist
Issue reference
KAG-1570