google-cloud-nio normally uses the default credentials, but there's an "escape hatch" to provide your own:
CloudStorageFileSystem.forBucket(String bucket, CloudStorageConfiguration config).
An unexpected side effect of the way the code is written is that when using custom credentials, bucket-to-bucket copies are slower.
The reason is that this creates a new CloudStorageFileSystemProvider. When asking for a copy across providers, NIO will read from one and write to the other (thus routing all the data via the client's computer). Instead, when it's the same provider, NIO can use the far more efficient copy method (data then don't have to leave the datacenter).
A natural fix would be for our code to check whether the passed config was seen before and, if so, reuse the same CloudStorageFileSystemProvider. This could be done directly by our users as a workaround, but it makes sense for us to do it transparently.
cc:@mziccard, @jart
google-cloud-nionormally uses the default credentials, but there's an "escape hatch" to provide your own:CloudStorageFileSystem.forBucket(String bucket, CloudStorageConfiguration config).An unexpected side effect of the way the code is written is that when using custom credentials, bucket-to-bucket copies are slower.
The reason is that this creates a new
CloudStorageFileSystemProvider. When asking for a copy across providers, NIO will read from one and write to the other (thus routing all the data via the client's computer). Instead, when it's the same provider, NIO can use the far more efficient copy method (data then don't have to leave the datacenter).A natural fix would be for our code to check whether the passed
configwas seen before and, if so, reuse the sameCloudStorageFileSystemProvider. This could be done directly by our users as a workaround, but it makes sense for us to do it transparently.cc:@mziccard, @jart