dlmarion commented on PR #5375: URL: https://github.com/apache/accumulo/pull/5375#issuecomment-2695444345
> The difference seems to be more on the client side. The [loadFiles rpc](https://github.com/apache/accumulo/blob/bd9e67637c3ecc9e8a4e8d1ffbee26b8e7e84370/core/src/main/thrift-gen-java/org/apache/accumulo/core/tabletserver/thrift/TabletClientService.java#L458) only calls send on the client side. The [splitTablet rpc](https://github.com/apache/accumulo/blob/bd9e67637c3ecc9e8a4e8d1ffbee26b8e7e84370/core/src/main/thrift-gen-java/org/apache/accumulo/core/tabletserver/thrift/TabletClientService.java#L476) also has a void return type, but is not one way and it calls send and recv. The oneway does allow the client to spin up a bunch of work on tservers w/o waiting for each tserver, but that seems to have some undesirable side effects. I am going to experiment w/ dropping the oneway on the decleration and calling the send and recv methods separately. Right, but the send call in the `loadFiles` case won't return until `TabletClientHandler.loadFiles` is completed on the server side. I'm curious if the following could be done in parallel. https://github.com/apache/accumulo/blob/dacc3e972cdbda1ac83da415a8e42e4bb93db9bd/server/tserver/src/main/java/org/apache/accumulo/tserver/TabletClientHandler.java#L222-L246 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
