User-implementable SlotSupplier #1553
Conversation
Sushisource
force-pushed
the
user-slot-supplier
branch
2 times, most recently
from
871abb6 to
79cdf8e
Compare
Sushisource
force-pushed
the
user-slot-supplier
branch
from
8643c8c to
bce8b25
Compare
|
Requires #1553 to merge before it can compile |
Sushisource
changed the title
| /** | ||
| * The interface can be implemented to provide custom slot supplier behavior. | ||
| */ | ||
| export interface CustomSlotSupplier<SI extends SlotInfo> { |
There was a problem hiding this comment.
I noticed that a "maximum slots" getter isn't here. I think that's a good thing, just noticing the mismatch with Go/Java.
| reserveSlot(ctx: SlotReserveContext, abortSignal: AbortSignal): Promise<SlotPermit>; | ||
|
|
||
| /** | ||
| * This function is called when trying to reserve slots for "eager" workflow and activity tasks. |
There was a problem hiding this comment.
There's no case of eager workflow task in TS at this point. Might want to adjust the doc accordingly. Or not.
There was a problem hiding this comment.
I think I'll leave it as is for when we maybe reintroduce
| // Defaults to 1000 for workflow tasks and 2000 for activity tasks. | ||
| /** | ||
| * Maximum amount of slots permitted | ||
| * Defaults to 1000 for workflow tasks and 2000 for activity tasks. |
There was a problem hiding this comment.
I know this is not new from this PR, but reading this again makes me think… Isn't 1000/2000 ridiculously high as defaults? Or will this effectively get capped by some other limit anyway (I mean, something else than only resource usage).
IIRC, the default namespace config in Cloud is to limit the total number of polers to 2000. Could we get in a situation where the RB provider would allow that many slots in polling state at the same time, from the same worker?
Should we have a distinct limit for the number of slots that have been allowed but haven't yet been "marked as in-use"?
There was a problem hiding this comment.
Yeah, it is, but the idea is it's supposed to be capped by the resource tuner long before it gets to that point. So, not something else, but that.
Good question about the polling, but right now no way, and when I do poller tuning I'll have to consider that of course. Probably there is also just a different limit on max polling ceiling which will in effect restrict this (or this will be bound to that)
Sushisource
force-pushed
the
user-slot-supplier
branch
from
e2b51d8 to
35128e0
Compare
Sushisource
force-pushed
the
user-slot-supplier
branch
from
35128e0 to
cbb42de
Compare
What was changed
Add user-implementable slot suppliers
Why?
Parity. Cool feature.
Checklist
Closes
How was this tested:
Added tests
Any docs updates needed?
Yes, will be updating docs pages after all Core langs are done