registry: Try to continue iteration #131

Merged
dstepanov-yadro merged 1 commit from dstepanov-yadro/xk6-frostfs:fix/registry_selector into master 2024-09-04 19:51:18 +00:00

If selector has read all the objects then it tries first to continue iteration.

If selector has read all the objects then it tries first to continue iteration.
dstepanov-yadro force-pushed fix/registry_selector from 4502f3ddfc to 7db213f352 2024-03-19 14:22:02 +00:00 Compare
dstepanov-yadro force-pushed fix/registry_selector from 7db213f352 to cc90ad6070 2024-03-19 14:23:41 +00:00 Compare
dstepanov-yadro force-pushed fix/registry_selector from cc90ad6070 to 5745dba1fc 2024-03-19 14:25:17 +00:00 Compare
fyrchik reviewed 2024-03-19 14:28:17 +00:00
@ -167,7 +170,6 @@ func (o *ObjSelector) selectLoop() {
case <-o.ctx.Done():
return
}
lastID = 0
Owner

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, do we still have duplicates? It seems the culprit It was introduced in 3c26e7c9175 without justification in the commit message (which seemed to be a part of #86, but I cannot see the commit there).
Author
Member

With this change alone selector will read registry file only once. This affects read scenarios.

With this change alone selector will read registry file only once. This affects read scenarios.
Owner

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).

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).
Owner

To me "read-once" by default seems expected.

To me "read-once" by default seems expected.
Author
Member

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.

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.
Owner

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.

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.
Owner

It also doesn't need to be a parameter, maybe 2 different constructors.

It also doesn't need to be a parameter, maybe 2 different constructors.
Author
Member

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.

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.
Owner

The bug is exactly about the cycling behaviour: we do not need it if we want to remove each object exactly once.

The bug is exactly about the cycling behaviour: we do not need it if we want to remove each object exactly once.
Author
Member

The scenario is write+update+delete - 10 workers put objects, 10 workers update those objects, 10 workers delete updated objects. So with read-once update and delete workers will hang stop after first iteration.

The scenario is `write+update+delete` - 10 workers put objects, 10 workers update those objects, 10 workers delete updated objects. So with `read-once` update and delete workers will ~~hang~~ stop after first iteration.
Owner

No, because registry groups objects by status.
So we have update use read once object with status "created", then put them in registry with status "updated"
delete will read 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.

No, because registry groups objects by status. So we have `update` use `read once object with status "created", then put them in registry with status "updated"` `delete` will `read 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.
Author
Member

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.

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.
Author
Member

done

done
fyrchik marked this conversation as resolved
dstepanov-yadro requested review from storage-core-committers 2024-03-19 14:44:21 +00:00
dstepanov-yadro requested review from storage-core-developers 2024-03-19 14:44:21 +00:00
dstepanov-yadro force-pushed fix/registry_selector from 5745dba1fc to 6350c88c9e 2024-03-20 08:05:28 +00:00 Compare
fyrchik reviewed 2024-03-20 08:17:56 +00:00
fyrchik left a comment
Owner

After reformatting js code may be add clang-format to fmt target?

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
Owner

After looped addition, do we still need this change? It seems lastID=0 did the same thing.

After `looped` addition, do we still need this change? It seems `lastID=0` did the same thing.
Author
Member

done

done
fyrchik marked this conversation as resolved
dstepanov-yadro force-pushed fix/registry_selector from 6350c88c9e to 0a6e51ccc9 2024-03-20 08:42:08 +00:00 Compare
Author
Member

After reformatting js code may be add clang-format to fmt target?

I use clang-format-17, someone else may have different version. Anyway this js-files changed not so frequently I think.

> After reformatting js code may be add clang-format to fmt target? I use clang-format-17, someone else may have different version. Anyway this js-files changed not so frequently I think.
fyrchik approved these changes 2024-03-20 09:22:42 +00:00
aarifullin approved these changes 2024-03-20 10:12:45 +00:00
dstepanov-yadro merged commit 0a6e51ccc9 into master 2024-03-20 10:13:24 +00:00
dstepanov-yadro deleted branch fix/registry_selector 2024-03-20 10:13:25 +00:00
dstepanov-yadro referenced this pull request from a commit 2024-03-20 10:13:26 +00:00
Sign in to join this conversation.
No description provided.