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

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