[Refactoring] Abstract AsyncShardFetch cache to allow restructuring for batch mode

[amkhar]

Describe the bug

Overall project issue : #8098

AsyncShardFetch class cache is like private final Map<String, NodeEntry<T>> cache = new HashMap<>();
This is just a map which will always store the full response (T) returned from the data nodes when we want to get the metadata of shards after node-left/join. The responses from new transport return the data for all the shards in a map like Map<ShardId, ShardResponse>
So when we fill the cache it'll store the data like

Map<String, Map<ShardId, ShardResponse>>

This map stores the data for every nodeId, so ShardId will get repeated for every node. What we should do is not store the shardId in repeated manner but use some array to store just the data and keep ShardId mapping separately.

Current Map private final Map<String, NodeEntry<T>> cache can not support this use case.

Related issue for adding a new caching strategy for a batch of shards #12248

Related component

Cluster Manager

To Reproduce

N/A

Expected behavior

Current cache can not support other strategies. So abstracting out this implementation in a separate class will help other caching strategies to be implemented easily.
To have that restructuring in place, I'm suggesting to have three simple methods like

initData - Initialize the cache entry
getData - get the data from the cache
putData - store the data in the cache

Each caching strategy should implement these methods and handle how things should be done. And driver class should just care about node level response and executing the end to end flow (common functionalities to be put in base class to avoid duplication).

This way, new caching strategy for batch of shards would be able to put the response data in relevant format like in an array and get it accordingly. Existing implementation can be same.

Additional Details

N/A

[peternied]

[Triage - attendees 1 2 3 4 5]
@amkhar Thanks for creating this issue; however, it isn't being accepted due to the issue not having enough context on its own please recreate with more details. Please feel free to open a new issue after addressing the reason.

[amkhar]

Sure @peternied , I'll add more details in this issue itself (if it's okay to re-open with more details ?).

Just curious if you went through #12248 to understand how we want to implement the cache for new transport actions being written for a batch of shards ?

For that implementation to be clean, first we need to modify the current cache (map) into a class so existing implementation and new implementation can be put in separate child classes.

[peternied]

Just curious if you went through...

This issue was reviewed by the triage team during the core triage meeting, we read the issue as it is. While additional context / links are useful the general guidance is the problem and expected end state are clearly described in the issue.

if it's okay to re-open with more details

If you have the ability to do so, please feel free to reopen.

[amkhar]

Thanks for confirmation.
Added more details :)

[peternied]

[Triage - attendees 1 2 3 4 5]
@amkhar Thanks for the additional context - this issue looks good.

[amkhar]

Completed by #12441