[Bug] Overlook fallback when data-flush event enters into pending queue

[zuston]

Code of Conduct

• I agree to follow this project's Code of Conduct

Search before asking

• I have searched in the issues and found no similar issues.

Describe the bug

When using the storage type of MEMORY_LOCALFILE_HDFS and enable the fallback strategy of LocalStorageManagerFallbackStrategy, it will still fail when one disk reached high watermark.

After digging into the code, I found it is caused by the cache in MultiStorageManager when invoking the selectStorage in the method of ShuffleFlushManager.processPendingEvents, that make it lost the chance to use the fallback.

But after removing this cache, I still found it still fail, because this pending event's retries time always=0, so it will make fallback failed.

So I rethink this pending queue. Do we really need this in multiple storage? I think perhaps not, we could remove this pending queue mechanism when multiple storage manager is enabled. Of course, it's still meaningful for single storage manager.

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!

[zuston]

@xianjingfeng I found the fallback strategy is invalid. Could you help check this? CC @jerqi

[jerqi]

@xianjingfeng I found the fallback strategy is invalid. Could you help check this? CC @jerqi

I agree that we remove the pending queue. Because the concept is involved because we need to implement the function of HDFS upload.

[zuston]

Of course, it's still meaningful for single storage manager.

Do you agree this?

[jerqi]

Of course, it's still meaningful for single storage manager.

Do you agree this?

It seems that there is little impact. It's a little complicated.

[jerqi]

@xianjingfeng WDYT?

[xianjingfeng]

I agree to remove the pending queue. We can retry write directly when we use single storage manager.

[zuston]

Let's rethink the pending queue for single storage manager.

If the single disk is corrupted or free space is full, all events will be pushed to the pending queue, events could re-enter into flush queue once disk becomes healthy within the pending timeout. I don't know the initial design reason of this. But I think it could avoid events being dropped as much as possible, especially when disk is temporary out-of-service.

[jerqi]

Let's rethink the pending queue for single storage manager.

If the single disk is corrupted or free space is full, all events will be pushed to the pending queue, events could re-enter into flush queue once disk becomes healthy within the pending timeout. I don't know the initial design reason of this. But I think it could avoid events being dropped as much as possible, especially when disk is temporary out-of-service.

Agree. If you insist on this, we could keep this feature. I just want to simplify this process.

[zuston]

Fixed by #383