registry: Try to continue iteration #131
No reviewers
Labels
No labels
P0
P1
P2
P3
good first issue
Infrastructure
blocked
bug
config
discussion
documentation
duplicate
enhancement
go
help wanted
internal
invalid
kludge
observability
perfomance
question
refactoring
wontfix
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: TrueCloudLab/xk6-frostfs#131
Loading…
Reference in a new issue
No description provided.
Delete branch "dstepanov-yadro/xk6-frostfs:fix/registry_selector"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
If selector has read all the objects then it tries first to continue iteration.
4502f3ddfc
to7db213f352
7db213f352
tocc90ad6070
cc90ad6070
to5745dba1fc
@ -167,7 +170,6 @@ func (o *ObjSelector) selectLoop() {
case <-o.ctx.Done():
return
}
lastID = 0
With this change alone, do we still have duplicates? It seems the culprit
It was introduced in
3c26e7c917
without justification in the commit message (which seemed to be a part of #86, but I cannot see the commit there).With this change alone selector will read registry file only once. This affects read scenarios.
Can we made an explicit opt-in/opt-out for this behaviour? It seems that in each scenario we want a specific semantics (for read -- read many times, for delete -- read once).
To me "read-once" by default seems expected.
But for write + update + delete
read once
doesn't work too.There have been no other comments on this behavior in 8 months. That's why I think it's not necessary to complicate things.
For write + update + delete we use a different selector for each step.
I don't see how it complicates things, other than making them more explicit.
The default is up to you, but each time you create a selector you probably want one specific behaviour, not a random combination of two.
It also doesn't need to be a parameter, maybe 2 different constructors.
Now selector is simple: it just reads objects in a circle. This works fine with the most common scenarios: write+read and read.
I have not received any
read once
-behavior requests from QA. So I don't think it is really required.The bug is exactly about the cycling behaviour: we do not need it if we want to remove each object exactly once.
The scenario is
write+update+delete
- 10 workers put objects, 10 workers update those objects, 10 workers delete updated objects. So withread-once
update and delete workers willhangstop after first iteration.No, because registry groups objects by status.
So we have
update
useread once object with status "created", then put them in registry with status "updated"
delete
willread once object with status "updated", then put then in registry with status "deleted"
.The behaviour was there before the
3c26e7c917
, where a bug was introduced to support read scenarios. A proper solution would've been to do exactly what we need: introduce cycling behaviour for selectors only for read scenarios.Then I don't understand what you mean by
read-once
:(Current implementation always tries to continue iteration first. If there is no new items, it starts from the beginning. This allows to work with update and read scenarios without any additional flags.
done
5745dba1fc
to6350c88c9e
After reformatting js code may be add clang-format to fmt target?
@ -125,6 +127,9 @@ func (o *ObjSelector) selectLoop() {
if keyBytes != nil && decodeId(keyBytes) == lastID {
keyBytes, objBytes = c.Next()
}
if o.looped && keyBytes == nil { // if no more items added then try to start from the beginning
After
looped
addition, do we still need this change? It seemslastID=0
did the same thing.done
6350c88c9e
to0a6e51ccc9
I use clang-format-17, someone else may have different version. Anyway this js-files changed not so frequently I think.