Skip to content

Meta: handle every notification from block #3259

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

Closed
carpawell opened this issue Mar 28, 2025 · 0 comments · Fixed by #3272
Closed

Meta: handle every notification from block #3259

carpawell opened this issue Mar 28, 2025 · 0 comments · Fixed by #3272
Assignees
Labels
bug Something isn't working I4 No visible changes neofs-storage Storage node application issues S4 Routine U1 Critically important to resolve quickly
Milestone

Comments

@carpawell
Copy link
Member

carpawell commented Mar 28, 2025

Meta relies on order much. Object notifications were synced via raw block handling in #3219. Container creation and deletion are still done via separate subs channels.

Expected Behavior

Container PUT/DELETE can also be a part of the raw block handling and the order of object handling can be straight without any racing.

Current Behavior

Container drop is done via a separate routine as an optimization. (Un)subscription is our usual danger of neo-go's deadlock. Container creation and container removal may have a race.

Possible Solution

Use

case h, ok := <-m.bCh:
if !ok {
err := m.reconnect(ctx)
if err != nil {
return err
}
continue
}
m.blockBuff <- h
for every notification (parsing logic may become a little more complex).

Steps to Reproduce (for bugs)

SearchV2 tests with fast container delete/create locked notifications and required kludges.

carpawell added a commit that referenced this issue Mar 28, 2025
It is prohibited to make RPC calls if you are not reading notification channel.
If last container removal and new container creation are events from a single
block, 7ec47bd deadlocks in its
(re)subscription subroutines. The logic will be improved in the future when
every notification is handled in a strict order: #3259.

Signed-off-by: Pavel Karpy <[email protected]>
carpawell added a commit that referenced this issue Mar 28, 2025
It is prohibited to make RPC calls if you are not reading notification channel.
If last container removal and new container creation are events from a single
block, 7ec47bd deadlocks in its
(re)subscription subroutines. The logic will be improved in the future when
every notification is handled in a strict order: #3259.

Signed-off-by: Pavel Karpy <[email protected]>
carpawell added a commit that referenced this issue Mar 28, 2025
It is prohibited to make RPC calls if you are not reading notification channel.
If last container removal and new container creation are events from a single
block, 7ec47bd deadlocks in its
(re)subscription subroutines. The logic will be improved in the future when
every notification is handled in a strict order: #3259.

Signed-off-by: Pavel Karpy <[email protected]>
carpawell added a commit that referenced this issue Mar 28, 2025
It is prohibited to make RPC calls if you are not reading notification channel.
If last container removal and new container creation are events from a single
block, 7ec47bd deadlocks in its
(re)subscription subroutines. The logic will be improved in the future when
every notification is handled in a strict order: #3259.

Signed-off-by: Pavel Karpy <[email protected]>
@roman-khimov roman-khimov added bug Something isn't working neofs-storage Storage node application issues U1 Critically important to resolve quickly S4 Routine I4 No visible changes labels Mar 28, 2025
@roman-khimov roman-khimov added this to the v0.46.0 milestone Mar 28, 2025
carpawell added a commit that referenced this issue Apr 4, 2025
Do not subscribe for containers additionally, use blocks as a single source of
notifications. Now meta service is always in one of the two mutually exclusive
state:
1. IDLE: subscribed to new containers event and not subscribed to blocks
2. ACTIVE: subscribed to blocks and not subscribed to new containers

Refs #3175, closes #3259.

Signed-off-by: Pavel Karpy <[email protected]>
carpawell added a commit that referenced this issue Apr 4, 2025
Do not subscribe for containers additionally, use blocks as a single source of
notifications. Now meta service is always in one of the two mutually exclusive
state:
1. IDLE: subscribed to new containers event and not subscribed to blocks
2. ACTIVE: subscribed to blocks and not subscribed to new containers

Refs #3175, closes #3259.

Signed-off-by: Pavel Karpy <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working I4 No visible changes neofs-storage Storage node application issues S4 Routine U1 Critically important to resolve quickly
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants