-
Notifications
You must be signed in to change notification settings - Fork 37
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
Complex object is not readable through non-container node #2447
Comments
|
we couldn't longer just forward GET request to container node starting from 907f427 @carpawell do u remember why we prevented assembly within local requests? this limit seems pretty strange to me. TTL should control hops of the request only but not it's processing |
despite the fact that the container node refuses to collect the object because of the TTL, why can't the first recipient of the request collect it? currently it is expected because server cannot associate the requested child object with its parent referenced by the session token. Because of this, in a private container, a out-of-contianer node does not have enough rights, which can be seen from the error log. See #1420 |
May be related to #838. |
the problem is definitely caused by TTL:
therefore, to fix this bug, at least one of following changes is required:
to me:
@roman-khimov @carpawell what do u think? |
I think 1. is correct in general if it is forwarding without any request changes. But if we change request (even with some minimal meta info) that is not forwarding to me and should decrease TTL. The only TTL non-decreasing operation to me is forwarding that does not allow you to understand that forwarder ever existed. |
every change may break some cases in theory. What cases? |
TTL is there mostly to avoid endless forwarding, to me it's mostly the problem of our approach to it as "local request". Distinguishing small/big object requests just shouldn't rely on TTL to me. |
I do remember that i have tested smth in the object assembly process with TTL 1. But we may consider this as a kludge. |
This reverts commit 907f427. GET requests with TTL=1 are absolutely correct regardless of the need to assemble the object. This TTL blocks request forwarding - it does not happen. At the same time, assembling an object on the server spawns new requests from scratch, which is not forwarding. The original commit does not have a description of the cause, and it was never discovered. Fixes #2447. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
This reverts commit 907f427. GET requests with TTL=1 are absolutely correct regardless of the need to assemble the object. This TTL blocks request forwarding - it does not happen. At the same time, assembling an object on the server spawns new requests from scratch, which is not forwarding. The original commit does not have a description of the cause, and it was never discovered. Fixes #2447. Signed-off-by: Leonard Lyubich <leonard@morphbits.io>
This value is better be known to users and it's better be more than two since we can have more complicated communications in future. Refs. nspcc-dev/neofs-node#2447 Signed-off-by: Roman Khimov <roman@nspcc.ru>
This value is better be known to users and it's better be more than two since we can have more complicated communications in future. Refs. nspcc-dev/neofs-node#2447 Signed-off-by: Roman Khimov <roman@nspcc.ru>
i tried to exec several ops with complex objects on https://github.com/nspcc-dev/neofs-dev-env
steps to reproduce:
make prepare.ir
3 nodes respond correctly, 1 fails with error
log record on the failed node about the operation:
seems like session is lost when out-of-container node spawns new requests or the session doesn't work
Versions
a9b92f53f7913fc28d4eb307a671030d87a7ecab
(with NeoFS v0.37.0 too)The text was updated successfully, but these errors were encountered: