Support multi coordinator while serving query state info#16163
Support multi coordinator while serving query state info#16163tdcmeehan merged 1 commit intoprestodb:masterfrom
Conversation
8770903 to
3adb730
Compare
There was a problem hiding this comment.
I think, given the asynchronous nature of the work in this method, it makes sense to make it completely async.
Look at examples in the codebase for:
- Using
@Suspended AsyncResponse asyncResponseto asynchronously return results in the endpoint. Futures.transform/Futures.transformAsyncto avoid blocking on the results of the futures.
There was a problem hiding this comment.
It makes a lot of sense to make it non blocking and leverage asyncResponse here. I have made the changes.
There was a problem hiding this comment.
Is this a pure refactoring or are there new tests introduced as part of it?
Also, I would prefer to just duplicate what's needed between the two tests. There's no need IMO to introduce an inheritance hierarchy.
There was a problem hiding this comment.
Agree unless it's a shared tests that we want to run, lets not introduce inheritance in tests.
There was a problem hiding this comment.
I think I did this to leverage same multi coordinator setup and teardown for both tests, but I agree we should avoid inheritance for the tests. I will make the change and may be leverage util/rules to share common stuff between the tests.
There was a problem hiding this comment.
instead of pulling all info from RM, we could just use the other coordinator query info from RM and merge it with the existing query info. Not a must but a good to have optimization.
There was a problem hiding this comment.
I think we can do this optimization. Only caveat is that we need to do back and forth GET-POST conversion while proxying request between coordinator and RM. I looked at the changes required for this and this seems like a relatively bigger one to add on top of the existing changes. I will create a separate PR for addressing this optimization.
There was a problem hiding this comment.
Agree unless it's a shared tests that we want to run, lets not introduce inheritance in tests.
1170aca to
286b755
Compare
| { | ||
| try { | ||
| Set<InternalNode> coordinators = internalNodeManager.getCoordinators(); | ||
| List<ListenableFuture<List<QueryStateInfo>>> queryStateInfoFutureList = new ArrayList<>(); |
There was a problem hiding this comment.
In general we use immutable data structures. Here I would either stream through the coordinators, perform the action and collect() it into an toImmutableList(), or use an ImmutableList.Builder
There was a problem hiding this comment.
I have to get used to immutable data structures :) I made the changes to use ImmutableList.Builder
| private static final JsonCodec<List<QueryStateInfo>> JSON_CODEC = JsonCodec.listJsonCodec(QueryStateInfo.class); | ||
| private final ResourceManagerClusterStateProvider clusterStateProvider; | ||
| private final InternalNodeManager internalNodeManager; | ||
| private ListeningExecutorService executor; |
| public class DistributedQueryInfoResource | ||
| { | ||
| private static final Logger log = Logger.get(DistributedQueryInfoResource.class); | ||
| private static final JsonCodec<List<QueryStateInfo>> JSON_CODEC = JsonCodec.listJsonCodec(QueryStateInfo.class); |
There was a problem hiding this comment.
Typically this is wired in via Guice. See existing codecs defined in ResourceManagerModule.
There was a problem hiding this comment.
Thanks for checking this! I missed this, it makes sense to use Guice here. I made the changes.
0dd8aa8 to
1083051
Compare
1083051 to
04a5a7b
Compare
tdcmeehan
left a comment
There was a problem hiding this comment.
One question, otherwise LGTM
There was a problem hiding this comment.
I think the logic here is simple enough, and not proxy-like enough, that it should just be implemented inline in this class. i.e. let's remove the changes to add this to the RM proxy, as it's not really proxying, it's just performing the request.
There was a problem hiding this comment.
Makes sense since this class is meant to be used for proxy like stuff. I was using it like a client helper earlier. I made the change.
310f2aa to
948ad88
Compare
There was a problem hiding this comment.
There's technically nothing here that is specific to multi-coordinator setup or resource manager. Shall we rename this class to something like QueryExecutionClientUtil? I would also suggest making the HTTP client a parameter, that way we can just static import these methods in the tests that use them.
There was a problem hiding this comment.
It was earlier named as a test helper to be used for tests under resource manager package, but it makes sense to move these to specific utils and we can use it in other tests as well if required. I made the changes.
93a302f to
9ed08fd
Compare
Currently /v1/queryState/* endpoints serve query state info available within a particular coordinator. The change here is to enable these endpoints to retrieve cluster wide query state info.
9ed08fd to
0cd03a3
Compare
Currently /v1/queryState/* endpoints serve query state info available within a particular coordinator. The change here is to enable these endpoints to retrieve cluster wide query state info.
Test plan - Verified though unit test and TpchQueryRunner