datastax-oss.atlassian.net
Open in
urlscan Pro
185.166.143.37
Public Scan
URL:
https://datastax-oss.atlassian.net/browse/JAVA-1196
Submission: On November 29 via api from NL — Scanned from CH
Submission: On November 29 via api from NL — Scanned from CH
Form analysis
1 forms found in the DOM<form id="jira_request_timing_info" class="dont-default-focus">
<fieldset class="parameters hidden">
<input type="hidden" title="jira.request.trace.id" value="b8912627340b4aaeb23d2d028bb9bf1f">
<input type="hidden" title="jira.request.sampled" value="false">
<input type="hidden" title="jira.request.start.millis" value="1701227486946">
<input type="hidden" title="jira.request.server.time" value="628">
<input type="hidden" title="jira.request.server.head.time" value="67">
<input type="hidden" title="jira.request.id" value="778d1d064f1cc90d6b9445df4a55eecf">
<input type="hidden" title="jira.session.expiry.time" value="-">
<input type="hidden" title="jira.session.expiry.in.mins" value="-">
<input id="jiraConcurrentRequests" type="hidden" name="jira.request.concurrent.requests" value="8">
</fieldset>
</form>
Text Content
Skip to: 1. Zur Jira-Navigation springen 2. Zur Seitennavigation springen 3. Zum Hauptinhalt springen DataStax Projekte Filter Dashboards Apps Erstellen DATASTAX JAVA DRIVER FOR APACHE CASSANDRA Softwareprojekt Berichte VorgängeKomponenten Sie befinden sich in einem vom Unternehmen verwalteten Projekt 1. Projekte DataStax Java Driver... JAVA-1361 JAVA-1196 INCLUDE HASH OF RESULT SET METADATA IN PREPARED STATEMENT ID BESCHREIBUNG Initial description: This issue is related to CASSANDRA-10786. In short, when the table is altered (column is added), the wildcard queries keep the old result metadata and never return the added column for all but the very first client (as the very first client is the only one that receives UNPREPARED statement. After adding result metadata to md5 on Cassandra side, as the message metadata on the client is never updated and new client ID of the re-prepared message is not saved anywhere, client would fall into the infinite re-prepare loop: * (1) try running the query * fail with UNPREPARED * re-prepare (although without saving the new ID) * go to (1) I first tried to transparently swap the request when getting UNPREPARED, although that would mean that the original "outdated" prepared query would re-prepare no matter how many times it runs (even though results it returns would be correct). On the other hand, making changes in the BoundStatement itself (or in it's PreparedStatement) might lead to undesired behaviour on the client-side or even be prone to races (when request is sent assuming one id and metadata and came back after it got swapped). Question is what'd be a good solution for such situation? Should we try and update the metadata everywhere in all bound statements or simply throw an exception and force the client to re-prepare the query? I've attached the "test" file to illustrate the problem a bit better. -------------------------------------------------------------------------------- Resolution: See the updated description of CASSANDRA-10786. UMGEBUNG Keine PULL REQUESTS Kein Wert ANHÄNGE (1) * VERKNÜPFTE VORGÄNGE IS BLOCKED BY JAVA-1248 Add "beta" native protocol flag Erledigt RELATES TO JAVA-955 Driver can enter a indeterminately completing prepare loop if cassandra nodes don't consistently generate the same ID for a prepared statement Geschlossen RESOLVES JAVA-420 Prepared statement reads wrong column after columns are added to table Erledigt AKTIVITÄT Anzeigen: AlleKommentareVerlaufArbeitsprotokoll Neueste zuerst OLIVIER MICHALLAT 2. MÄRZ 2017 UM 00:21 Removing from 3.2.0 since the Cassandra ticket is scheduled for 3.11. ALEX DUTRA 17. JANUAR 2017 UM 12:39 The link above was for JAVA-1248, an updated pull-request for this ticket can be found here: https://github.com/datastax/java-driver/pull/787 ALEX P 14. OKTOBER 2016 UM 20:25 Final patch can be found here: https://github.com/datastax/java-driver/pull/718 ALEX P 22. JUNI 2016 UM 09:23 I've changed the implementation a bit since we decided to take a different approach. Cassandra patch got some positive feedback. Could anyone also review the driver patch? Patch itself https://github.com/ifesdjeen/java-driver/tree/10786-v5 Cassandra issue Thanks! ALEX P 18. MAI 2016 UM 13:25 I've made a proof-of-concept patch https://github.com/datastax/java-driver/tree/10786-3.0. In order for it to work, one would need corresponding Cassandra built from https://github.com/ifesdjeen/cassandra/tree/10786-trunk. You can run C* either straight from the repo (ant && ./bin/cassandra -f`) or with CCM ccm create 10786-trunk --install-dir=path_to_repo. And a little background/motivation for why the patch looks like it looks: There was an idea to try substituting the old `preparedId` for DefaultPreparedStatement, but If we swap `DefaultPreparedStatement:reparedId`, we still have the instances of old `PreparedStatements` hanging (for example one we originally got here with). So the "original" prepared statements won't be influenced. Every time we will bind and run `execute` with them again, the issue will be the same. The test is there for sakes of illustration for now. I'll create a better suite if/when we agree on how we would like to proceed with the change. Erledigt Behoben Aktionen Felder mit Pins Klicken Sie neben einer Feldbeschriftung auf , um sie anzupinnen. Details ZUGEWIESENE PERSON Nicht zugewiesen AUTOR Alex P STICHWORT protocol_v5 LÖSUNGSVERSIONEN DSE-1.6.0 3.3.2 DSE-1.4.2 SPRINT Java 4.x PRIORITÄT Schwerwiegend Erstellt 17. Mai 2016 um 12:36 Aktualisiert 20. November 2017 um 21:50 Erledigt 19. Oktober 2017 um 23:34 Konfigurieren FLAG NOTIFICATIONS Es ist ein Problem aufgetreten. Anscheinend wurden Sie abgemeldet. Versuchen Sie, sich erneut einzuloggen. Einloggen