Attempted to parallelize bulk import loading #5375

keith-turner · 2025-03-01T22:36:51Z

While profiling bulk load v2 noticed that the manager would send a message to a tablet containing a lot of tablets to load. The tablet server would process each tablet one at time and do a metadata write for it. This caused a lot of serial metadata writes per tablet server which caused this part of bulk import to take longer.

Attempted to parallelize these metadata writes by changing the manager to send a RPC per tablet. The hope was that the tablet server would process each RPC request in a separate thread and this would avoid the serial metadata writes.

However this is not currently working and I am not sure why. The manager is getting a thrift client and then sending a lot of one way RPCs to load tablets. These one way messages all appear to be being processed by a single thread on the tablet servers. Still investigating why this happening, if anyone knows more about this please let me know.

While profiling bulk load v2 noticed that the manager would send a message to a tablet that contained a lot of tablets to load. The tablet server would process each tablet one at time and do a metadata write for it. This caused a lot of serial metadata writes per tablet server which caused this part of bulk import to take longer. Attempted to parallelize these metadata writes by changing the manager to send a RPC per tablet. The hope was that the tablet server would process each RPC request in a separate thread and this would avoid the serial metadata writes. However this is not currently working and I am not sure why. The manager is getting a thrift client and then sending a lot of one way RPCs to load tablets. These one way messages all appear to be being processed by a single thread on the tablet servers. Still investigating why this happening, if anyone knows more about this please let me know.

keith-turner · 2025-03-01T22:38:04Z

server/manager/src/main/java/org/apache/accumulo/manager/tableOps/bulkVer2/LoadFiles.java

+            // the metadata tablet which requires waiting on the walog. Sending a message per tablet
+            // allows these per tablet metadata table writes to run in parallel. This avoids
+            // serially waiting on the metadata table write for each tablet.
+            for (var entry : tabletFiles.entrySet()) {


This is the code that I changed to do an RPC per tablet instead of per tablet server. I was hoping these would execute in parallel on the tablet server, but that does not seem to be happening.

keith-turner · 2025-03-01T22:38:42Z

server/base/src/main/java/org/apache/accumulo/server/rpc/CustomNonBlockingServer.java

@@ -119,6 +119,7 @@ public CustomFrameBuffer(TNonblockingTransport trans, SelectionKey selectionKey,
      super(trans, selectionKey, selectThread);
      // Store the clientAddress in the buffer so it can be referenced for logging during read/write
      this.clientAddress = getClientAddress();
+      log.debug("created custom frame buffer ", new Exception());


This was added as debug while trying to understand what is going on.

keith-turner · 2025-03-01T22:39:22Z

server/tserver/src/main/java/org/apache/accumulo/tserver/TabletClientHandler.java

@@ -243,6 +245,8 @@ public void loadFiles(TInfo tinfo, TCredentials credentials, long tid, String di
            server.removeBulkImportState(files);
          }
        }
+        UtilWaitThread.sleep(100);


Addes this sleep so that I could verify things were running concurrently in the tserver and never saw that happen.

keith-turner · 2025-03-01T22:40:42Z

@ctubbsii and @dlmarion curious if you have any insight into why the thrift one way messages are not executing in parallel on the tablet server.

ctubbsii · 2025-03-02T01:01:47Z

@ctubbsii and @dlmarion curious if you have any insight into why the thrift one way messages are not executing in parallel on the tablet server.

I thought there was some issue you found awhile back that indicated there was an issue with the thrift server type that made it use a small number of threads (maybe one) for handling RPC requests. I don't recall the details.

dlmarion · 2025-03-03T14:05:41Z

@ctubbsii and @dlmarion curious if you have any insight into why the thrift one way messages are not executing in parallel on the tablet server.

I thought there was some issue you found awhile back that indicated there was an issue with the thrift server type that made it use a small number of threads (maybe one) for handling RPC requests. I don't recall the details.

It looks our default Thrift server type will end up creating a custom non-blocking Thrift server with one accept thread. If the value of GENERAL_RPC_SERVER_TYPE is set to threadpool, then it ends up creating a Thrift server will multiple select threads. I would suggest making this change to see if you see a difference. It's possible that the tablet server's single accept thread is busy working on other RPCs and hasn't gotten around to the one you are interested in yet.

dlmarion · 2025-03-03T14:16:39Z

Related to my earlier comment, it looks like you (@keith-turner ) created an issue in Thrift for the TThreadedSelectorServer (https://issues.apache.org/jira/browse/THRIFT-4847). It looks like this was fixed in Thrift 0.21, so you may need to update Thrift in this branch as well.

keith-turner · 2025-03-03T15:13:46Z

The reminders about the select thread were helpful. I was assuming that the thrift code would read frames per RPC into memory and queue those frames on a thread pool. It may instead queue the connection and the frame on thread pool, returning the connection for selection when the task completes on the pool. If so that would mean only one thing will ever execute per connection, even if the message is oneway and no response is needed. Going to look into this a bit more and see if that is the case.

dlmarion · 2025-03-03T15:23:41Z

The reminders about the select thread were helpful. I was assuming that the thrift code would read frames per RPC into memory and queue those frames on a thread pool. It may instead queue the connection and the frame on thread pool, returning the connection for selection when the task completes on the pool. If so that would mean only one thing will ever execute per connection, even if the message is oneway and no response is needed. Going to look into this a bit more and see if that is the case.

I think that in the case of the other threaded server implementations (TnonBlockingServer, for example), there is one select thread that reads the request from the connection, then hands it off to a thread in the worker thread pool. I don't think that the accept threads wait for the worker thread to complete in this case, so it's somewhat asynchronous. I could be wrong about this, but it makes sense on the surface. There could be cases where the accept thread could take a long time though to complete the task of reading the request and assigning it to a worker thread. For example, if only some of the packets have arrived on the interface for the request and the client has not sent them all yet.

keith-turner · 2025-03-03T16:22:54Z

Made changes in 551dde0 to use mutliple connections per tserver in the manager. Seeing parallelism on the tserver side w/ this change.

This behavior is making me wonder about connection pooling plus one way messages. Maybe a situation like the following could happen, want to test this.

Client thread T1 get connection C1 from pool and send s a one way rpc RPC1.
Tserver thread T2 starts processing RPC1
Client thread T1 returns C1 to pool, eveything up to this point took a few ms.
Client thread T2 gets connection C1 and calls RPC2, however RPC2 will block until RPC1 is done on tsever
Tserver thread T2 finishes processing RPC1 after 10 seconds and then starts working on RPC2
Client thread T2 finishes RPC2 call after 10+ seconds. It was delayed a by the previously submitted one way

It may be that a connection obtained from the pool could actually have multiple one way messages queued on it that must be processed before it will actually do anything.

keith-turner · 2025-03-03T16:41:18Z

Still have not taken a deep dive into the thrift code. As more is understood about this, would be good to asses the impact on the managers use of one way messages to load tablets and the implications for parallel tablet loads.

dlmarion · 2025-03-03T17:51:41Z

Looking at the Thrift code for our default server type (CustomNonBlockingServer extends THsHaServer extends TNonblockingServer), I think our oneway RPC methods are not asynchronous.
In TNonblockingServer.SelectAcceptThread.select, handleAccept is called which creates either a synchronous or asynchronous FrameBuffer. Then handleRead is called which ends up calling requestInvoke which just calls invoke on the created FrameBuffer.

The createFrameBuffer method that is called from handleAccept creates either a AsyncFrameBuffer or FrameBuffer depending on the whether or not the Processor is asynchronous (see https://github.com/apache/thrift/blob/0.17.0/lib/java/src/main/java/org/apache/thrift/TProcessorFactory.java#L37). We wrap all of our Processors with the TimedProcessor class, which does not implement AsyncProcessor.

You can see in FrameBuffer.invoke that the RPC method is called, then the responseReady method. Conversely, in AsyncFrameBuffer.invoke you can see that the Processor is cast to a TAsyncProcessor, then the process method is called. Looking at TBaseAsyncProcessor.process snippet below you can see that responseReady is called, then the method is invoked.

https://github.com/apache/thrift/blob/60655d2de79e973b89fab52af82f9628d4843b0f/lib/java/src/main/java/org/apache/thrift/TBaseAsyncProcessor.java#L96-L108

I'm not sure what oneway with synchronous processing on the worker thread buys us. I don't see how it's any different than a method that returns void. I assume that this pattern is in use with the other Thrift server types. I think this is consistent with your observation about using multiple clients above, except that you may not have been aware that each client won't return until the method is done processing on the server side.

Edit: Also, if we did fix TimedProcessor to implement TAsyncProcessor, the TMultipledProcessor that it is wrapping does not implement it. I'm not sure why, or what the issue would be with invoking it in an async manner.

Update: Looks like https://issues.apache.org/jira/browse/THRIFT-2427 was created for the async multiplexed processor. A PR was created, but never merged.

keith-turner · 2025-03-03T19:54:23Z

You can see in FrameBuffer.invoke that the RPC method is called, then the responseReady method.

Following that responseReady() method in AbstractNonBlockingServer it eventually calls this code which I believe makes the connection available for the selection thread to use again. For the Sync case this is called after the message is processed server side.

I'm not sure what oneway with synchronous processing on the worker thread buys us. I don't see how it's any different than a method that returns void. I assume that this pattern is in use with the other Thrift server types. I think this is consistent with your observation about using multiple clients above, except that you may not have been aware that each client won't return until the method is done processing on the server side.

The difference seems to be more on the client side. The loadFiles rpc only calls send on the client side. The splitTablet rpc 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.

dlmarion · 2025-03-03T20:16:42Z

The difference seems to be more on the client side. The loadFiles rpc only calls send on the client side. The splitTablet rpc 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.

accumulo/server/tserver/src/main/java/org/apache/accumulo/tserver/TabletClientHandler.java

Lines 222 to 246 in dacc3e9

    
             Map<TabletFile,MapFileInfo> newFileMap = new HashMap<>(); 
        
             for (Entry<String,MapFileInfo> mapping : fileMap.entrySet()) { 
        
               Path path = new Path(dir, mapping.getKey()); 
        
               FileSystem ns = context.getVolumeManager().getFileSystemByPath(path); 
        
               path = ns.makeQualified(path); 
        
               newFileMap.put(new TabletFile(path), mapping.getValue()); 
        
             } 
        
             var files = newFileMap.keySet().stream().map(TabletFile::getPathStr).collect(toList()); 
        
             server.updateBulkImportState(files, BulkImportState.INITIAL); 
        
             Tablet importTablet = server.getOnlineTablet(KeyExtent.fromThrift(tke)); 
        
             if (importTablet != null) { 
        
               try { 
        
                 server.updateBulkImportState(files, BulkImportState.PROCESSING); 
        
                 importTablet.importMapFiles(tid, newFileMap, setTime); 
        
               } catch (IOException ioe) { 
        
                 log.debug("files {} not imported to {}: {}", fileMap.keySet(), 
        
                     KeyExtent.fromThrift(tke), ioe.getMessage()); 
        
               } finally { 
        
                 server.removeBulkImportState(files); 
        
               } 
        
             } 
        
           });

keith-turner · 2025-03-03T21:55:33Z

Right, but the send call in the loadFiles case won't return until TabletClientHandler.loadFiles is completed on the server side.

That does not seem to be the behavior I am seeing based on logging from running the new test against 551dde0. Below are some of the following logs where by the time the manager has sent 999 one way messages not a single tablet has completed bulk load processing in a tserver.

$ grep sent Manager_1222094219.out | head
2025-03-03T21:17:41,722 99 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 999 messages to 2 tablet servers in 80 ms
2025-03-03T21:17:42,309 97 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 989 messages to 2 tablet servers in 21 ms
2025-03-03T21:17:42,826 98 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 974 messages to 2 tablet servers in 14 ms
2025-03-03T21:17:43,341 96 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 954 messages to 2 tablet servers in 8 ms
2025-03-03T21:17:43,801 97 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 930 messages to 2 tablet servers in 6 ms
2025-03-03T21:17:44,272 98 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 895 messages to 2 tablet servers in 5 ms
2025-03-03T21:17:44,710 98 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 860 messages to 2 tablet servers in 4 ms
2025-03-03T21:17:45,112 99 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 820 messages to 2 tablet servers in 4 ms
2025-03-03T21:17:45,502 99 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 775 messages to 2 tablet servers in 3 ms
2025-03-03T21:17:45,853 98 [bulkVer2.LoadFiles] DEBUG: FATE[31d804b6af250c68] sent 715 messages to 2 tablet servers in 2 ms
$ grep -e Starting -e Finished TabletServer_1604342290.out | head
2025-03-03T21:17:41,732 94 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0138;0137 
2025-03-03T21:17:41,732 88 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0584;0583 
2025-03-03T21:17:41,740 57 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0660;0659 
2025-03-03T21:17:41,741 93 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0177;0176 
2025-03-03T21:17:41,744 64 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0024;0023 
2025-03-03T21:17:41,745 96 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0202;0201 
2025-03-03T21:17:41,746 62 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0253;0252 
2025-03-03T21:17:41,747 58 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0292;0291 
2025-03-03T21:17:41,836 88 [tserver.TabletClientHandler] DEBUG: Finished bulk import  for 2;0584;0583 
2025-03-03T21:17:41,836 94 [tserver.TabletClientHandler] DEBUG: Finished bulk import  for 2;0138;0137 
$ grep -e Starting -e Finished TabletServer_1604342290.out | head
2025-03-03T21:17:41,732 94 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0138;0137 
2025-03-03T21:17:41,732 88 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0584;0583 
2025-03-03T21:17:41,740 57 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0660;0659 
2025-03-03T21:17:41,741 93 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0177;0176 
2025-03-03T21:17:41,744 64 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0024;0023 
2025-03-03T21:17:41,745 96 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0202;0201 
2025-03-03T21:17:41,746 62 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0253;0252 
2025-03-03T21:17:41,747 58 [tserver.TabletClientHandler] DEBUG: Starting bulk import  for 2;0292;0291 
2025-03-03T21:17:41,836 88 [tserver.TabletClientHandler] DEBUG: Finished bulk import  for 2;0584;0583 
2025-03-03T21:17:41,836 94 [tserver.TabletClientHandler] DEBUG: Finished bulk import  for 2;0138;0137

Notice how the manager code keeps queueing work up for the tablet servers in the messages above by continually sending these one way messages. Eventually a bunch of these run after the bulk import is done.

$ grep "no longer active" TabletServer_1* | head -3
TabletServer_1097069005.out:2025-03-03T21:17:52,169 86 [zookeeper.TransactionWatcher] DEBUG: Transaction 3591625885496970344 of type bulkTx is no longer active.
TabletServer_1097069005.out:2025-03-03T21:17:52,169 58 [zookeeper.TransactionWatcher] DEBUG: Transaction 3591625885496970344 of type bulkTx is no longer active.
TabletServer_1097069005.out:2025-03-03T21:17:52,170 75 [zookeeper.TransactionWatcher] DEBUG: Transaction 3591625885496970344 of type bulkTx is no longer active.
$ grep "no longer active" TabletServer_1* | wc
  13988  181844 2252068

I'm curious if the following could be done in parallel.

I considered that when I started looking into this but did not want to create yet another thread pool that needs to be configured and monitored. Figured could use the existing RPC thread pool. That may be a way to solve this, would probably be best to have a thread pool per tserver for this as opposed to per request.

dlmarion · 2025-03-03T22:00:46Z

I considered that when I started looking into this but did not want to create yet another thread pool that needs to be configured and monitored. Figured could use the existing RPC thread pool. That may be a way to solve this, would probably be best to have a thread pool per tserver for this as opposed to per request.

Good news is that there are already properties for the thread pools being used in the client for bulk v1, but are labeled TSERV.

keith-turner · 2025-03-03T22:16:09Z

In a5f8b88 made the following changes

Removed the oneway from the thrift call
In the manager changed the code to call send_loadFiles RPC for all connections w/o waiting on result
In a second loop go through and call recv_loadFiles for all connections

This change has a nice advantage that is unrelated to initial goal of parallelization. The current bulk code w/ one way messages only knows if somethnig is done by scanning the metadata table. Because the changes in a5f8b88 waits for the tablets servers it does not keep scanning the metadata table and then sending more one way messages queuing up more uneeded work for the tablet servers, causing more metadata scans, and having to guess when things are done.

The following are some log message from running the new test w/ the changes in a5f8b88

$ grep sent Manager_200744172.out 
2025-03-03T22:10:44,362 98 [bulkVer2.LoadFiles] DEBUG: FATE[08ad9a5880022b01] sent 16 messages to 2 tablet servers, send time:8ms recv time:872ms
2025-03-03T22:10:44,811 98 [bulkVer2.LoadFiles] DEBUG: FATE[08ad9a5880022b01] sent 0 messages to 0 tablet servers, send time:0ms recv time:0ms

keith-turner · 2025-03-04T16:09:20Z

Good news is that there are already properties for the thread pools being used in the client for bulk v1, but are labeled TSERV.

That could work, it would depend on the behavior of the bulkv1 and bulkv2 code that use the prop. If bulkv1 and bulkv2 code would need different settings for the property to be optimal on a system because of underlying behavior diffs in the use of the property then it would be confusing to reuse the property.

Thinking about the bulk v1 code and behavior, it would be nice if this fix for bulkv2 caused no changes in behavior for the bulkv1 code. Since both use the same RPC need to be careful about changing that RPC as it will impact bulkv1 and bulkv2.

ddanielr · 2025-03-04T18:25:45Z

Good news is that there are already properties for the thread pools being used in the client for bulk v1, but are labeled TSERV.

That could work, it would depend on the behavior of the bulkv1 and bulkv2 code that use the prop. If bulkv1 and bulkv2 code would need different settings for the property to be optimal on a system because of underlying behavior diffs in the use of the property then it would be confusing to reuse the property.

I agree that we shouldn't reuse the bulkv1 threadpool property.

Users will probably want to run jobs back to back using bulkv1 and bulkv2 configurations to compare results.
Minimizing the amount of configuration changes needed for that switch would be ideal.

Thinking about the bulk v1 code and behavior, it would be nice if this fix for bulkv2 caused no changes in behavior for the bulkv1 code. Since both use the same RPC need to be careful about changing that RPC as it will impact bulkv1 and bulkv2.

Is there a requirement for keeping the same RPC as bulkv1?

keith-turner · 2025-03-07T21:40:06Z

Is there a requirement for keeping the same RPC as bulkv1?

No, if changing the behavior of the existing RPC is desired it would probably be best to create a new rpc for bulkv2 and leave bulkv1 as is. Creating a new RPC creates headache for a mix of 2.1.3 and 2.1.4 server processes. These RPCs are only used by servers so at least it would not impact clients.

Added a new synch bulk load RPC for bulk v2. Added a new property to control concurrency for bulk v2. Reverted the changes to the existing RPC used by bulk v1. The new RPC should hopefully not cause any problems. A 2.1.3 manager working w/ 2.1.4 tablets servers should have no problems. A 2.1.4 manager working w/ a 2.1.3 tserver should log a message about version mismatch and the bulk fate should pause until tservers are updated. Need to manually test 2.1.4 manager and 2.1.3 tservers to ensure this works.

keith-turner · 2025-03-08T19:45:36Z

In 932efdc added a new RPC and a new property, also cleaned up a lot of loose ends. 932efdc should get to a point of causing no changes in behavior for bulkv1 w/ the new RPC. The changes in 932efdc should tolerate a mixture of 2.1.X server versions w/o causing bulk imports to fail, but I need to manually test this. After manually testing this plan to take this out of draft. The commit message for 932efdc has more details.

keith-turner · 2025-03-10T19:43:24Z

Tested this code w/ a 2.1.3 tserver, ran through the following steps

Started 2.1.4-SNAPSHOT instances w/ the changes in a616266.
Killed the 2.1.4-SNAPSHOT tservers
Started a 2.1.3 tserver using the 2.1.3 tar ball.
Ran bulkv2 import from the shell which paused w/ the expected log message in the manager.
Killed the 2.1.3 tserver and then started 2.1.4-SNAPSHOT tservers
The bulk import eventually completed successfully.

Saw messages like the following in the manager logs when the 2.1.3 tserver was running.

2025-03-10T19:29:22,134 [bulkVer2.LoadFiles] DEBUG: rpc failed server (tserver may be running older version): localhost:10000, FATE[2274c546c7c58381]
org.apache.thrift.TApplicationException: Invalid method name: 'loadFilesV2'
	at org.apache.thrift.TServiceClient.receiveBase(TServiceClient.java:81) ~[libthrift-0.17.0.jar:0.17.0]
	at org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Client.recv_loadFilesV2(TabletClientService.java:501) ~[accumulo-core-2.1.4-SNAPSHOT.jar:2.1.4-SNAPSHOT]
	at org.apache.accumulo.manager.tableOps.bulkVer2.LoadFiles$OnlineLoader.sendQueued(LoadFiles.java:258) ~[accumulo-manager-2.1.4-SNAPSHOT.jar:2.1.4-SNAPSHOT]

ddanielr

Just some minor suggestions. Overall the changes make sense to me and look correct.

ddanielr · 2025-03-12T17:45:25Z

server/manager/src/main/java/org/apache/accumulo/manager/tableOps/bulkVer2/LoadFiles.java

+        // Even though this code waited, it does not know what succeeded on the tablet server side
+        // and it did not track if there were connection errors. Since success status is unknown
+        // must return a non-zero sleep to indicate another scan of the metadata table is needed.
+        sleepTime = 1;


Removing that long sleep is a nice improvement.

server/manager/src/main/java/org/apache/accumulo/manager/tableOps/bulkVer2/LoadFiles.java

…Ops/bulkVer2/LoadFiles.java Co-authored-by: Daniel Roberts <ddanielr@gmail.com>

keith-turner commented Mar 1, 2025

View reviewed changes

remove experimental change that did not make a diff

f016945

use multiple connections

551dde0

keith-turner mentioned this pull request Mar 3, 2025

logs thread id for integration tests #5377

Merged

remove oneway and call send/recv seperately

a5f8b88

remove debugging added when tracking down issues

a616266

keith-turner marked this pull request as ready for review March 10, 2025 19:34

ddanielr reviewed Mar 12, 2025

View reviewed changes

keith-turner and others added 6 commits March 12, 2025 16:25

Update server/manager/src/main/java/org/apache/accumulo/manager/table…

e920687

…Ops/bulkVer2/LoadFiles.java Co-authored-by: Daniel Roberts <ddanielr@gmail.com>

Update server/manager/src/main/java/org/apache/accumulo/manager/table…

2f65c47

…Ops/bulkVer2/LoadFiles.java Co-authored-by: Daniel Roberts <ddanielr@gmail.com>

Update server/manager/src/main/java/org/apache/accumulo/manager/table…

4727fd3

…Ops/bulkVer2/LoadFiles.java Co-authored-by: Daniel Roberts <ddanielr@gmail.com>

Update server/manager/src/main/java/org/apache/accumulo/manager/table…

c7f1040

…Ops/bulkVer2/LoadFiles.java Co-authored-by: Daniel Roberts <ddanielr@gmail.com>

remove brace and format

dc2419e

reformat comment

c1e4f4e

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Attempted to parallelize bulk import loading #5375

Attempted to parallelize bulk import loading #5375

keith-turner commented Mar 1, 2025 •

edited

Loading

keith-turner Mar 1, 2025 •

edited

Loading

keith-turner Mar 1, 2025

keith-turner Mar 1, 2025

keith-turner commented Mar 1, 2025 •

edited

Loading

ctubbsii commented Mar 2, 2025

dlmarion commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

keith-turner commented Mar 3, 2025 •

edited

Loading

dlmarion commented Mar 3, 2025 •

edited

Loading

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

keith-turner commented Mar 4, 2025

ddanielr commented Mar 4, 2025

keith-turner commented Mar 7, 2025 •

edited

Loading

keith-turner commented Mar 8, 2025

keith-turner commented Mar 10, 2025 •

edited

Loading

ddanielr left a comment

ddanielr Mar 12, 2025

Attempted to parallelize bulk import loading #5375

Are you sure you want to change the base?

Attempted to parallelize bulk import loading #5375

Conversation

keith-turner commented Mar 1, 2025 • edited Loading

keith-turner Mar 1, 2025 • edited Loading

Choose a reason for hiding this comment

keith-turner Mar 1, 2025

Choose a reason for hiding this comment

keith-turner Mar 1, 2025

Choose a reason for hiding this comment

keith-turner commented Mar 1, 2025 • edited Loading

ctubbsii commented Mar 2, 2025

dlmarion commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

keith-turner commented Mar 3, 2025 • edited Loading

dlmarion commented Mar 3, 2025 • edited Loading

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

dlmarion commented Mar 3, 2025

keith-turner commented Mar 3, 2025

keith-turner commented Mar 4, 2025

ddanielr commented Mar 4, 2025

keith-turner commented Mar 7, 2025 • edited Loading

keith-turner commented Mar 8, 2025

keith-turner commented Mar 10, 2025 • edited Loading

ddanielr left a comment

Choose a reason for hiding this comment

ddanielr Mar 12, 2025

Choose a reason for hiding this comment

keith-turner commented Mar 1, 2025 •

edited

Loading

keith-turner Mar 1, 2025 •

edited

Loading

keith-turner commented Mar 1, 2025 •

edited

Loading

keith-turner commented Mar 3, 2025 •

edited

Loading

dlmarion commented Mar 3, 2025 •

edited

Loading

keith-turner commented Mar 7, 2025 •

edited

Loading

keith-turner commented Mar 10, 2025 •

edited

Loading