[ 
https://issues.apache.org/jira/browse/CASSANDRA-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Oleg Zhovtanyuk updated CASSANDRA-17263:
----------------------------------------
    Description: 
sstableloader silently ignores the storage port option and connects to the 
storage port of the server.

E.g.
{code:java}
sstableloader -v -d 192.168.1.24 -p 32181 -sp 32182 -u USER -pw PASSWORD 
backups/test-workspace/test-table-9150b730742911ec9d011fb0ef4f5206 {code}
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.
{code:java}
docker run -it \
  -p 32181:9042 \
  -p 32182:7000 \
cassandra:4.0.1{code}
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|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java#L83]):
{code:java}
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;
... {code}
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.

  was:
sstableloader silently ignores the storage port option and connects to the 
storage port of the server.

E.g.
{code:java}
sstableloader -v -d 192.168.1.24 -p 32181 -sp 32182 -u USER -pw PASSWORD 
backups/test-workspace/test-table-9150b730742911ec9d011fb0ef4f5206 {code}
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 (servers listens on port 7000 so just use it), but it does 
not work, when Cassandra runs in a Docker container, started via an 
orchestrator (Kubernetes, Mesos) with ports mapped.

E.g.

 
{code:java}
docker run -it \
  -p 32181:9042 \
  -p 32182:7000 \
cassandra:4.0.1{code}
 

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|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java#L83])
{code:java}
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;
... {code}
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.


> sstableloader ignores the storage port option
> ---------------------------------------------
>
>                 Key: CASSANDRA-17263
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17263
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Tools
>            Reporter: Oleg Zhovtanyuk
>            Priority: Normal
>
> sstableloader silently ignores the storage port option and connects to the 
> storage port of the server.
> E.g.
> {code:java}
> sstableloader -v -d 192.168.1.24 -p 32181 -sp 32182 -u USER -pw PASSWORD 
> backups/test-workspace/test-table-9150b730742911ec9d011fb0ef4f5206 {code}
> 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.
> {code:java}
> docker run -it \
>   -p 32181:9042 \
>   -p 32182:7000 \
> cassandra:4.0.1{code}
> 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|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/utils/NativeSSTableLoaderClient.java#L83]):
> {code:java}
> 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;
> ... {code}
> 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.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to