You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems reasonable that regard applicationid as user, because it is more safe. But we know the max number of hadoop user is 16777215, it is limited. Even though the related remote storage directory is deleted, this user string won't be delete from SerialNumberMap util restart namenode.
Affects Version(s)
master
Uniffle Server Log Output
No response
Uniffle Engine Log Output
No response
Uniffle Server Configurations
No response
Uniffle Engine Configurations
No response
Additional context
No response
Are you willing to submit PR?
Yes I am willing to submit a PR!
The text was updated successfully, but these errors were encountered:
### What changes were proposed in this pull request?
tez application should use login ugi to communicate with shuffle sever, but not applicationid ugi.
### Why are the changes needed?
Fix: #1109
### Does this PR introduce _any_ user-facing change?
No.
### How was this patch tested?
test in real cluster.
Code of Conduct
Search before asking
Describe the bug
When we use remote storage, we will flush data to hdfs, but the user of the storage is appid. See the storage:
It seems reasonable that regard applicationid as user, because it is more safe. But we know the max number of hadoop user is 16777215, it is limited. Even though the related remote storage directory is deleted, this user string won't be delete from SerialNumberMap util restart namenode.
Affects Version(s)
master
Uniffle Server Log Output
No response
Uniffle Engine Log Output
No response
Uniffle Server Configurations
No response
Uniffle Engine Configurations
No response
Additional context
No response
Are you willing to submit PR?
The text was updated successfully, but these errors were encountered: