CustomPayload should be used to provide customization via a custom query handler (that is outside of Cassandra source). Supporting custom timeout per query is a new feature. It is more clear to assign a dedicated query flag. In V5, the available number of query flags expanded from 8 (in V4 and prior) to 32. We do not need to piggyback the custom payload. Using a dedicated flag gives the same forward and backward compatibility as custom payload.
On Tue, Feb 18, 2020 at 2:28 PM David Capwell <dcapw...@gmail.com> wrote: > Given the JIRA in question, if you want to override the timeout to lower > it, then the worst case if not supported yet is that you get the default > timeout. So this then makes me wonder "is there a way to add metadata to a > message which is ignored if unknown" (aka forward compatibility). Skimming > the frame code i see we have > > boolean isCustomPayload = > frame.header.flags.contains(Frame.Header.Flag.CUSTOM_PAYLOAD); > boolean hasWarning = > frame.header.flags.contains(Frame.Header.Flag.WARNING); > > UUID tracingId = isRequest || !isTracing ? null : > CBUtil.readUUID(frame.body); > List<String> warnings = isRequest || !hasWarning ? null : > CBUtil.readStringList(frame.body); > Map<String, ByteBuffer> customPayload = !isCustomPayload ? null : > CBUtil.readBytesMap(frame.body); > > This makes me wonder if we could picky back off that for new features, that > way older servers just ignore them. I have no idea of the negatives of > customPayload (other than strings are more bytes for messages, evolution > may be based off key names so annoying, etc.), but tags which are ignored > sounds promising > > > On Tue, Feb 18, 2020 at 1:53 PM Jeff Jirsa <jji...@gmail.com> wrote: > > > A few notes: > > > > - Protocol changes add work to the rest of the ecosystem. Drivers have to > > update, etc. > > - Nobody expects protocol changes in minors, though it's less of a > concern > > if we don't deprecate out the older version. E.g. if 4.0 launches with > > protocol v4 and protocol v5, and then 4.0.2 adds protocol v6, do we > > deprecate out v4? If yes, you potentially break clients that only > supported > > v3 and v4 in a minor version upgrade, which is unexpected. If not, how > many > > protocol versions are you willing to support at any given time? > > - Having protocol changes introduces risk. Paging behavior across > protocol > > versions is the site of a number of different bugs recently. > > > > > > On Tue, Feb 18, 2020 at 1:46 PM Tolbert, Andrew <x...@andrewtolbert.com> > > wrote: > > > > > I don't know the technical answer, but I suspect two motivations for > > > doing new protocol versions in major releases could include: > > > > > > * protocol changes can be tied to feature changes that typically come > > > in a major release. > > > * protocol changes should be as infrequent as major releases. Each > > > new protocol version is another thing in the test matrix that needs to > > > be tested. > > > > > > That last point can make it hard to get new changes in. If something > > > doesn't make the upcoming protocol version, it might be years before > > > another one, but I also think it's worth it to do this infrequently as > > > it makes maintaining client and server code easier if there are less > > > protocol versions to worry about. > > > > > > On the client-side, libraries themselves should be avoiding making > > > Cassandra version checks when detecting capabilities. There are a few > > > exceptions, such as system table parsing for schema & peers, > > > but those aren't related to the protocol. > > > > > > Thanks, > > > Andy > > > > > > > > > > > > > > > > > > On Tue, Feb 18, 2020 at 1:22 PM Nate McCall <zznat...@gmail.com> > wrote: > > > > > > > > [Moving to new message thread] > > > > > > > > Thanks for bringing this up, Jordan. > > > > > > > > IIRC, this was more a convention than a technical reason. Though I > > could > > > be > > > > completely misremembering this. > > > > > > > > ---------- Forwarded message --------- > > > > From: Jordan West <jorda...@gmail.com> > > > > Date: Wed, Feb 19, 2020 at 10:13 AM > > > > Subject: Re: 20200217 4.0 Status Update > > > > To: <dev@cassandra.apache.org> > > > > > > > > > > > > On Mon, Feb 17, 2020 at 12:52 PM Jeff Jirsa <jji...@gmail.com> > wrote: > > > > > > > > > > > > > > beyond the client proto change being painful for anything other > than > > > major > > > > > releases > > > > > > > > > > > > > > This came up during the community meeting today and I wanted to > bring a > > > > question about it to the list: could someone who is *very* familiar > > with > > > > the client proto share w/ the list why changing the proto in anything > > > other > > > > than a major release is so difficult? I hear this a lot and it seems > to > > > be > > > > fact. So that all of us don't have to go read the code, a brief > summary > > > > would be super helpful. Or if there is a ticket that already covers > > this > > > > even better! I'd also be curious if there have ever been any thoughts > > to > > > > address it as it seems to be a consistent hurdle during the release > > cycle > > > > and one that tends to further increase scope. > > > > > > > > Thanks, > > > > Jordan > > > > > > > > > > > > > > > > > > > > On Feb 17, 2020, at 12:43 PM, Jon Meredith < > jmeredit...@gmail.com> > > > > > wrote: > > > > > > > > > > > > My turn to give an update on 4.0 status. The 4.0 board created > by > > > Josh > > > > > can > > > > > > be found at > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355. > > > > > > > > > > > > > > > > > > We have 94 unresolved tickets marked against the 4.0 release. [1] > > > > > > > > > > > > > > > > > > Things seem to have settled into a phase of working to resolve > > > issues, > > > > > with > > > > > > few new issues added. > > > > > > > > > > > > > > > > > > 2 new tickets opened (that are marked against 4.0) > > > > > > > > > > > > 11 tickets closed (including one of the newly opened ones) > > > > > > > > > > > > 39 tickets received updates to JIRA of some kind in the last week > > > > > > > > > > > > > > > > > > Cumulative flow over the last couple of weeks shows todo reducing > > and > > > > > done > > > > > > increasing as it should as we continue to close out work for the > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&view=reporting&chart=cumulativeFlowDiagram&swimlane=939&swimlane=936&swimlane=931&column=1505&column=1506&column=1514&column=1509&column=1512&column=1507&days=14 > > > > > > > > > > > > > > > > > > Notables > > > > > > > > > > > > - Python 3 support for cqlsh has been committed (thank you all > who > > > > > > persevered on this) > > > > > > > > > > > > - Some activity on Windows support - perhaps not dead yet. > > > > > > > > > > > > - Lots of movement on documentation > > > > > > > > > > > > - Lots of activity on flaky tests. > > > > > > > > > > > > - Oldest ticket with a patch award goes to CASSANDRA-2848 > > > > > > > > > > > > > > > > > > There are 18 tickets marked as patch available (easy access from > > the > > > > > > Dashboard [2], apologies if they're already picked up for review) > > > > > > > > > > > > > > > > > > CASSANDRA-15567 Allow EXTRA_CLASSPATH to work in tarball/source > > > > > > installations > > > > > > > > > > > > CASSANDRA-15553 Preview repair should include sstables from > > finalized > > > > > > incremental repair sessions > > > > > > > > > > > > CASSANDRA-15550 Fix flaky test > > > > > > org.apache.cassandra.streaming.StreamTransferTaskTest > > > > > > testFailSessionDuringTransferShouldNotReleaseReferences > > > > > > > > > > > > CASSANDRA-15488/CASSANDRA-15353 Configuration file > > > > > > > > > > > > CASSANDRA-15484/CASSANDRA-15353 Read Repair > > > > > > > > > > > > CASSANDRA-15482/CASSANDRA-15353 Guarantees > > > > > > > > > > > > CASSANDRA-15481/CASSANDRA-15353 Data Modeling > > > > > > > > > > > > CASSANDRA-15393/CASSANDRA-15387 Add byte array backed cells > > > > > > > > > > > > CASSANDRA-15391/CASSANDRA-15387 Reduce heap footprint of commonly > > > > > allocated > > > > > > objects > > > > > > > > > > > > CASSANDRA-15367 Memtable memory allocations may deadlock > > > > > > > > > > > > CASSANDRA-15308 Fix flakey testAcquireReleaseOutbound - > > > > > > org.apache.cassandra.net.ConnectionTest > > > > > > > > > > > > CASSANDRA-1530 5Fix multi DC nodetool status output > > > > > > > > > > > > CASSANDRA-14973 Bring v5 driver out of beta, introduce v6 before > > 4.0 > > > > > > release is cut > > > > > > > > > > > > CASSANDRA-14939 fix some operational holes in incremental repair > > > > > > > > > > > > CASSANDRA-14904 SSTableloader doesn't understand listening for > CQL > > > > > > connections on multiple ports > > > > > > > > > > > > CASSANDRA-14842 SSL connection problems when upgrading to 4.0 > when > > > > > > upgrading from 3.0.x > > > > > > > > > > > > CASSANDRA-14761 Rename speculative_retry to match > > > > additional_write_policy > > > > > > > > > > > > CASSANDRA-2848 Make the Client API support passing down timeouts > > > > > > > > > > > > > > > > > > *LHF / Failing Tests*: We have 7 unassigned test failures that > are > > > all > > > > > > > > > > > > great candidates to pick up and get involved in: > > > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=355&projectKey=CASSANDRA&quickFilter=1660&quickFilter=1661&quickFilter=1658 > > > > > > > > > > > > > > > > > > Thanks again to everybody for all the contributions. It's really > > > good to > > > > > > see the open issue count start dropping. > > > > > > > > > > > > > > > > > > Feedback on whether this information is useful and how it can be > > > > improved > > > > > > is both welcome and appreciated. > > > > > > > > > > > > > > > > > > Cheers, Jon > > > > > > > > > > > > > > > > > > [1] Unresolved 4.0 tickets > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/CASSANDRA-15567?filter=12347782&jql=project%20%3D%20cassandra%20AND%20fixversion%20in%20(4.0%2C%204.0.0%2C%204.0-alpha%2C%204.0-beta)%20AND%20status%20!%3D%20Resolved > > > > > > > > > > > > [2] Patch Available > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12334910 > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
