[CASSANDRA-10539] Different encodings used between nodes can cause inconsistently generated prepared statement ids

• Type: Bug
• Status: Resolved
• Priority: Low
• Resolution: Duplicate
• Severity: Low
• Assignee: Unassigned
• Reporter: Andy Tolbert
• Created: 16/Oct/15 04:38
• Updated: 16/Apr/19 09:30
• Resolved: 26/Nov/15 09:58

Description

From the java-driver mailing list / JAVA-955

If you have nodes in your cluster that are using a different default character set it's possible for nodes to generate different prepared statement ids for the same 'keyspace + query string' combination. I imagine this is not a very typical or desired configuration (thus the low severity).

This is because MD5Digest.compute(String) uses String.getBytes() which relies on the default charset.

In the general case this is fine, but if you use some characters in your query string such as Character.MAX_VALUE ('\uffff') the byte representation may vary based on the coding.

I was able to reproduce this configuring a 2-node cluster with node1 using file.encoding UTF-8 and node2 using file.encoding ISO-8859-1. The java-driver test that demonstrates this can be found here.

Issue Links

• duplicates: CASSANDRA-10755 PreparedStatement is the same id for different Japanese katakana characters with same length