Details
-
Bug
-
Status: Triage Needed
-
Normal
-
Resolution: Unresolved
-
None
-
None
-
All
-
None
Description
sstableloader silently ignores the storage port option and connects to the storage port of the server.
E.g.
sstableloader -v -d 192.168.1.24 -p 32181 -sp 32182 -u USER -pw PASSWORD backups/test-workspace/test-table-9150b730742911ec9d011fb0ef4f5206
Here sstableloader will ignore the storage port 32182 and try to connect to port 7000, if the server reports itself listening on port 7000.
This seems natural (server listens on port 7000 so just use it), but it does not work, when Cassandra runs in a Docker container with ports mapped - a normal cases for orchestrators (Kubernetes, Mesos).
E.g.
docker run -it \ -p 32181:9042 \ -p 32182:7000 \ cassandra:4.0.1
Here the storage port will be 7000 inside the container (and Cassandra server exposes it), but outside the container the port is 32182.
The code (NativeSSTableLoaderClient - link):
Set<Host> endpoints = metadata.getReplicas(Metadata.quote(keyspace), tokenRange); ... for (Host endpoint : endpoints) { int broadcastPort = endpoint.getBroadcastSocketAddress().getPort(); // use port from broadcast address if set. int portToUse = broadcastPort != 0 ? broadcastPort : storagePort; ...
It effectively ignores the storagePort, taken from CLI option. I believe, CLI option should have a priority here - let the user to decide what he wants.