[jira] [Comment Edited] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
[ https://issues.apache.org/jira/browse/CASSANDRA-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17560942#comment-17560942 ] Ivan Senic edited comment on CASSANDRA-6936 at 6/30/22 9:12 AM: Do I understand correct that this will be first available in the `4.2` release that is scheduled to go out in a year? was (Author: JIRAUSER281556): Do I understand good that this will be first available in the `4.2` release that is scheduled to go out in a year? > Make all byte representations of types comparable by their unsigned byte > representation only > > > Key: CASSANDRA-6936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6936 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Branimir Lambov >Priority: Normal > Labels: compaction, performance > Fix For: 4.2 > > Time Spent: 25h > Remaining Estimate: 0h > > This could be a painful change, but is necessary for implementing a > trie-based index, and settling for less would be suboptimal; it also should > make comparisons cheaper all-round, and since comparison operations are > pretty much the majority of C*'s business, this should be easily felt (see > CASSANDRA-6553 and CASSANDRA-6934 for an example of some minor changes with > major performance impacts). No copying/special casing/slicing should mean > fewer opportunities to introduce performance regressions as well. > Since I have slated for 3.0 a lot of non-backwards-compatible sstable > changes, hopefully this shouldn't be too much more of a burden. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-6936) Make all byte representations of types comparable by their unsigned byte representation only
[ https://issues.apache.org/jira/browse/CASSANDRA-6936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17560942#comment-17560942 ] Ivan Senic commented on CASSANDRA-6936: --- Do I understand good that this will be first available in the `4.2` release that is scheduled to go out in a year? > Make all byte representations of types comparable by their unsigned byte > representation only > > > Key: CASSANDRA-6936 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6936 > Project: Cassandra > Issue Type: Improvement > Components: Legacy/Core >Reporter: Benedict Elliott Smith >Assignee: Branimir Lambov >Priority: Normal > Labels: compaction, performance > Fix For: 4.2 > > Time Spent: 25h > Remaining Estimate: 0h > > This could be a painful change, but is necessary for implementing a > trie-based index, and settling for less would be suboptimal; it also should > make comparisons cheaper all-round, and since comparison operations are > pretty much the majority of C*'s business, this should be easily felt (see > CASSANDRA-6553 and CASSANDRA-6934 for an example of some minor changes with > major performance impacts). No copying/special casing/slicing should mean > fewer opportunities to introduce performance regressions as well. > Since I have slated for 3.0 a lot of non-backwards-compatible sstable > changes, hopefully this shouldn't be too much more of a burden. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-17401) Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache
[ https://issues.apache.org/jira/browse/CASSANDRA-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17497383#comment-17497383 ] Ivan Senic commented on CASSANDRA-17401: [~ifesdjeen] [~e.dimitrova] You can close the issue. I do understand the on execution of the prepared statement it will be re-prepared if the cache does not contain it. We ll adapt usage in Stargate. > Race condition in QueryProcessor causes just prepared statement not to be in > the prepared statements cache > -- > > Key: CASSANDRA-17401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17401 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Senic >Priority: Normal > > The changes in the > [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] > method that were introduced in versions *4.0.2* and *3.11.12* can cause a > race condition between two threads trying to concurrently prepare the same > statement. This race condition can cause removing of a prepared statement > from the cache, after one of the threads has received the result of the > prepare and eventually uses MD5Digest to call > [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. > The race condition looks like this: > * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 executes eviction of hashes > * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 prepares the statement and caches it > * Thread1 returns the result of the prepare > * Thread2 executes eviction of hashes > * Thread1 tries to execute the prepared statement with the received > MD5Digest, but statement is not in the cache as it was evicted by Thread2 > I tried to reproduce this by using a Java driver, but hitting this case from > a client side is highly unlikely and I can not simulate the needed race > condition. However, we can easily reproduce this in Stargate (details > [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to > QueryProcessor. > Reproducing this in a unit test is fairly easy. I am happy to showcase this > if needed. > Note that the issue can occur only when safeToReturnCached is resolved as > false. -- 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
[jira] [Commented] (CASSANDRA-17401) Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache
[ https://issues.apache.org/jira/browse/CASSANDRA-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17496911#comment-17496911 ] Ivan Senic commented on CASSANDRA-17401: [~ifesdjeen] I have to admin that internals of Cassandra are not 100% familiar to me. However, wouldn't there be a _PreparedQueryNotFoundException_ thrown in the _ExecuteMessage_ or the _BatchMessage_ if the _QueryHandler.getPrepared_ returns null? I don't know how this is exception handled or how is the re-preparing actually working. Maybe I was not clear in my explanation above, but bottom line is that if the race condition is uncovering the issue described, the _QueryHandler.getPrepared_ will return null for the MD5 that was just returned by the same class prepare method call. If you think this is acceptable, then you can close the issue. > Race condition in QueryProcessor causes just prepared statement not to be in > the prepared statements cache > -- > > Key: CASSANDRA-17401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17401 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Senic >Priority: Normal > > The changes in the > [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] > method that were introduced in versions *4.0.2* and *3.11.12* can cause a > race condition between two threads trying to concurrently prepare the same > statement. This race condition can cause removing of a prepared statement > from the cache, after one of the threads has received the result of the > prepare and eventually uses MD5Digest to call > [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. > The race condition looks like this: > * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 executes eviction of hashes > * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 prepares the statement and caches it > * Thread1 returns the result of the prepare > * Thread2 executes eviction of hashes > * Thread1 tries to execute the prepared statement with the received > MD5Digest, but statement is not in the cache as it was evicted by Thread2 > I tried to reproduce this by using a Java driver, but hitting this case from > a client side is highly unlikely and I can not simulate the needed race > condition. However, we can easily reproduce this in Stargate (details > [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to > QueryProcessor. > Reproducing this in a unit test is fairly easy. I am happy to showcase this > if needed. > Note that the issue can occur only when safeToReturnCached is resolved as > false. -- 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
[jira] [Updated] (CASSANDRA-17401) Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache
[ https://issues.apache.org/jira/browse/CASSANDRA-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Senic updated CASSANDRA-17401: --- Description: The changes in the [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] method that were introduced in versions *4.0.2* and *3.11.12* can cause a race condition between two threads trying to concurrently prepare the same statement. This race condition can cause removing of a prepared statement from the cache, after one of the threads has received the result of the prepare and eventually uses MD5Digest to call [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. The race condition looks like this: * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 executes eviction of hashes * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 prepares the statement and caches it * Thread1 returns the result of the prepare * Thread2 executes eviction of hashes * Thread1 tries to execute the prepared statement with the received MD5Digest, but statement is not in the cache as it was evicted by Thread2 I tried to reproduce this by using a Java driver, but hitting this case from a client side is highly unlikely and I can not simulate the needed race condition. However, we can easily reproduce this in Stargate (details [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to QueryProcessor. Reproducing this in a unit test is fairly easy. I am happy to showcase this if needed. Note that the issue can occur only when safeToReturnCached is resolved as false. was: The changes in the [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] method that were introduced in versions *4.0.2* and *3.11.12* can cause a race condition between two threads trying to concurrently prepare the same statement. This race condition can cause removing of a prepared statement from the cache, after one of the threads has received the result of the prepare and eventually uses MD5Digest to call [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. The race condition looks like this: * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 executes eviction of hashes * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 prepares the statement and caches it * Thread1 returns the result of the prepare * Thread2 executes eviction of hashes * Thread1 tries to execute the prepared statement with the received MD5Digest, but statement is not in the cache as it was evicted by Thread2 I tried to reproduce this by using a Java driver, but hitting this case from a client side is highly unlikely and I can not simulate the needed race condition. However, we can easily reproduce this in Stargate (details [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to QueryProcessor. Reproducing this in a unit test is fairly easy. I am happy to showcase this if needed. Note that the issue can occur only when safeToReturnCached is resolved as false. > Race condition in QueryProcessor causes just prepared statement not to be in > the prepared statements cache > -- > > Key: CASSANDRA-17401 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17401 > Project: Cassandra > Issue Type: Bug >Reporter: Ivan Senic >Priority: Normal > > The changes in the > [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] > method that were introduced in versions *4.0.2* and *3.11.12* can cause a > race condition between two threads trying to concurrently prepare the same > statement. This race condition can cause removing of a prepared statement > from the cache, after one of the threads has received the result of the > prepare and eventually uses MD5Digest to call > [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. > The race condition looks like this: > * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 executes eviction of hashes > * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false > * Thread1 prepares the statement and
[jira] [Created] (CASSANDRA-17401) Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache
Ivan Senic created CASSANDRA-17401: -- Summary: Race condition in QueryProcessor causes just prepared statement not to be in the prepared statements cache Key: CASSANDRA-17401 URL: https://issues.apache.org/jira/browse/CASSANDRA-17401 Project: Cassandra Issue Type: Bug Reporter: Ivan Senic The changes in the [QueryProcessor#prepare|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L575-L638] method that were introduced in versions *4.0.2* and *3.11.12* can cause a race condition between two threads trying to concurrently prepare the same statement. This race condition can cause removing of a prepared statement from the cache, after one of the threads has received the result of the prepare and eventually uses MD5Digest to call [QueryProcessor#getPrepared|https://github.com/apache/cassandra/blame/cassandra-4.0.2/src/java/org/apache/cassandra/cql3/QueryProcessor.java#L212-L215]. The race condition looks like this: * Thread1 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 executes eviction of hashes * Thread2 enters _prepare_ method and resolves _safeToReturnCached_ as false * Thread1 prepares the statement and caches it * Thread1 returns the result of the prepare * Thread2 executes eviction of hashes * Thread1 tries to execute the prepared statement with the received MD5Digest, but statement is not in the cache as it was evicted by Thread2 I tried to reproduce this by using a Java driver, but hitting this case from a client side is highly unlikely and I can not simulate the needed race condition. However, we can easily reproduce this in Stargate (details [here|https://github.com/stargate/stargate/pull/1647]), as it's closer to QueryProcessor. Reproducing this in a unit test is fairly easy. I am happy to showcase this if needed. Note that the issue can occur only when safeToReturnCached is resolved as false. -- 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
[jira] [Comment Edited] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460022#comment-17460022
]
Ivan Senic edited comment on CASSANDRA-17202 at 12/15/21, 3:00 PM:
---
Done.
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
was (Author: JIRAUSER281556):
Done:
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460022#comment-17460022
]
Ivan Senic commented on CASSANDRA-17202:
Done:
3.11: [https://github.com/apache/cassandra/pull/1364]
4.0: [https://github.com/apache/cassandra/pull/1365]
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459937#comment-17459937
]
Ivan Senic commented on CASSANDRA-17202:
The GitHub PR is updated as per request.
[~blerer] Are you saying I should create two more PRs, one targeting the
_cassandra-3.11_ and one _cassandra-4.0_ branch? The current PR targets the
{_}trunk{_}.
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458466#comment-17458466
]
Ivan Senic commented on CASSANDRA-17202:
[~blerer] I missed that.. Sure that's better and involves less changes.. Should
I update the PR?
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Bug
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Updated] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Senic updated CASSANDRA-17202:
---
Description:
In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found in
the prepared statements cache, there is always unnecessary string creation
using String.format in order to execute the _checkTrue_ assertion. The string
construction is necessary only when the queries are not equal.
{code:java}
public static ResultMessage.Prepared getStoredPreparedStatement(String
queryString, String clientKeyspace)
throws InvalidRequestException
{
MD5Digest statementId = computeId(queryString, clientKeyspace);
Prepared existing = preparedStatements.getIfPresent(statementId);
if (existing == null)
return null;
checkTrue(queryString.equals(existing.rawCQLStatement),
String.format("MD5 hash collision: query with the same MD5 hash was
already prepared. \n Existing: '%s'", existing.rawCQLStatement));
{code}
Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
getting on my nerves as it's popping up on my flame graphs all the time.
was:
In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found in
the prepared statements cache, there is always unnecessary string creation
using String.format in order to execute the _checkTrue_ assertion. The string
construction is necessary only when the queries are not equal.
{code:java}
public static ResultMessage.Prepared getStoredPreparedStatement(String
queryString, String clientKeyspace)
throws InvalidRequestException
{
MD5Digest statementId = computeId(queryString, clientKeyspace);
Prepared existing = preparedStatements.getIfPresent(statementId);
if (existing == null)
return null;
checkTrue(queryString.equals(existing.rawCQLStatement),
String.format("MD5 hash collision: query with the same MD5 hash was
already prepared. \n Existing: '%s'", existing.rawCQLStatement));
{code}
Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
getting in my nerves as it's popping up on my flame graphs all the time.
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Improvement
> Components: Messaging/Client
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Low
> Fix For: 4.x
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting on my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Commented] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
[
https://issues.apache.org/jira/browse/CASSANDRA-17202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17457170#comment-17457170
]
Ivan Senic commented on CASSANDRA-17202:
PR: https://github.com/apache/cassandra/pull/1358
> Avoid unnecessary String.format in QueryProcessor when getting stored
> prepared statement
> -
>
> Key: CASSANDRA-17202
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Ivan Senic
>Assignee: Ivan Senic
>Priority: Normal
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found
> in the prepared statements cache, there is always unnecessary string creation
> using String.format in order to execute the _checkTrue_ assertion. The string
> construction is necessary only when the queries are not equal.
> {code:java}
> public static ResultMessage.Prepared getStoredPreparedStatement(String
> queryString, String clientKeyspace)
> throws InvalidRequestException
> {
> MD5Digest statementId = computeId(queryString, clientKeyspace);
> Prepared existing = preparedStatements.getIfPresent(statementId);
> if (existing == null)
> return null;
> checkTrue(queryString.equals(existing.rawCQLStatement),
> String.format("MD5 hash collision: query with the same MD5 hash
> was already prepared. \n Existing: '%s'", existing.rawCQLStatement));
> {code}
> Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
> getting in my nerves as it's popping up on my flame graphs all the time.
>
--
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
[jira] [Created] (CASSANDRA-17202) Avoid unnecessary String.format in QueryProcessor when getting stored prepared statement
Ivan Senic created CASSANDRA-17202:
--
Summary: Avoid unnecessary String.format in QueryProcessor when
getting stored prepared statement
Key: CASSANDRA-17202
URL: https://issues.apache.org/jira/browse/CASSANDRA-17202
Project: Cassandra
Issue Type: Improvement
Reporter: Ivan Senic
Assignee: Ivan Senic
In the _QueryProcessor#getStoredPreparedStatement_ if the statement is found in
the prepared statements cache, there is always unnecessary string creation
using String.format in order to execute the _checkTrue_ assertion. The string
construction is necessary only when the queries are not equal.
{code:java}
public static ResultMessage.Prepared getStoredPreparedStatement(String
queryString, String clientKeyspace)
throws InvalidRequestException
{
MD5Digest statementId = computeId(queryString, clientKeyspace);
Prepared existing = preparedStatements.getIfPresent(statementId);
if (existing == null)
return null;
checkTrue(queryString.equals(existing.rawCQLStatement),
String.format("MD5 hash collision: query with the same MD5 hash was
already prepared. \n Existing: '%s'", existing.rawCQLStatement));
{code}
Hopefully the JIT can optimize this once the _checkTrue_ is inlined, but it's
getting in my nerves as it's popping up on my flame graphs all the time.
--
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
