Closed milleruntime closed 2 years ago
One issue seems to be that it's not prefixing the filesystem root directory for RawLocalFileSystem correctly. So, it's checking for a file relative to the root of the local filesystem, which is incorrect. This might have gone unnoticed with the globbing, because the glob never matched anything, whereas the current code now has a starting point in a directory it expects to exist.
A second issue is that the directory might not exist on all volumes, so we might need to have it ignore the case when there are no files on that specific volume. My concern doing this here, though, is that it might mask the first issue above, which should be fixed first.
I am not sure if the prefixing is causing the failure but the command works a few times in the IT up until it clones the table. After the clone, then it fails to find the second tableId. So there may be something else going on.
It looks like there is a change in the way that TableDiskUsage
behaves with the newly created table that has yet to be compacted. Before the recent change, the test would run the command (after cloning the table but before compacting) and only return results for one table:
diskUsages = accumuloClient.tableOperations().getDiskUsage(tables); assertEquals(1, diskUsages.size()); assertEquals(2, diskUsages.get(0).getTables().size()); assertTrue(diskUsages.get(0).getUsage() > 0);
So the files for the new table aren't there yet, until it gets compacted. Then when the command is run, it will return results for both tables.
Since the recent changes to TableDiskUsage
, an exception is now thrown because the file isn't found, instead of just quietly failing as it did before. The file isn't there yet because compaction hasn't run.
I am not sure if this is a problem, since it only seems to happen in the mini test with the RawFileSystem. I ran similar commands in the shell in Uno and it works fine. Do we want to change the behavior to make the test pass? Or change the test to pass for the new behavior?
If the file (or it appears directory in this case) does not exist, would it be appropriate to return a size of 0? Which, I think is your change the behavior option?
I am not sure if this is a problem, since it only seems to happen in the mini test with the RawFileSystem. I ran similar commands in the shell in Uno and it works fine.
I was mistaken. The command fails in Uno as well. Bottom line is that it doesn't handle clones. I think it might be a bug.
If the file (or it appears directory in this case) does not exist, would it be appropriate to return a size of 0? Which, I think is your change the behavior option?
I think that is one possible solution. The problem is I don't fully understand the code in TableDiskUsage
that tracks different sets of IDs so I am not sure where we need to make an adjustment.
Changes in 23fa7d48e7908b9af0a761fda431ffa0fc472a12 have caused a failure in the getDiskUsage test of TableOperationsIT. Here is where the error is happening in the test:
Here is the error that is being thrown in the tablet server: