Hi list, there is CASSANDRA-16999 which introduces native_port_ssl into system.peers_v2 table. The reasoning behind that is that without this, Cassandra Java Driver (both 3.x and 4.x branches) are not able to discover nodes when dual no-ssl / ssl communication is enabled.
To be more specific, if you have native_transport_port: 9042 and native_transport_port_ssl: 9142 in cassandra.yaml and you specify your contact point in the driver like 192.168.1.1:9142 in a three nodes cluster where all other nodes have 9042/9142 ports set, the driver will not load balance the traffic to the other nodes because the driver does not see ssl ports for peers in peers_v2 table so it will not include them / it breaks the discovery logic there. I think this is quite a serious issue and should be fixed from 4.0 to trunk. I prepared patches from 4.0 to trunk but as we looked at it closer, we would be introducing a new column to a system table in patch releases (for 4.0 and 4.1 at least) and I am not completely sure this is what we want. Also, if there is currently a user who e.g. reads from peers_v2 table and retrieves the value from a column by some index, then this would be "shifted" and it might break her reading. I am not sure how to evaluate the risk and the probability of this happening in practice but I consider it important to mention that. The cleanest solution would be to introduce this to trunk only where a new virtual table system_views.peers was introduced as part of TCM and it basically contains all information from system.peers_v2, it is just populated differently. Hence, the driver would read from this vtable. I do not know if we want to apply the patches to patch releases and fix this bug or we are OK with applying it just to trunk fully accepting that users will not be able to use Cassandra with both native_transport_port and native_transport_port_ssl set up in connection with the driver trying to connect to ssl port and expecting that the traffic will be load balanced. What is your opinion? Regards
