The length of table names was not controlled. This is likely due to
confusion between validation methods with similar names. As result
creating tables with too long names led to the too long file name
exceptions during table creations.
This commit adds a validation of table name lengths to avoid the too
long file name errors. The validation length is based on how the table
name is used to create file/directory names, and needs to be exact to
prevent the too long file name exception, but allow all other table
names, which didn't lead to the too long file name exception. This
length limit is different from the existing name length limit of 48
characters used by common validation functions.
Thus, this commit moves out the length validation from the validation
methods into a separate length validation method, so the errors on
names are more specific. The non-length validation methods combined
into a single method, which checks for empty names and valid characters.
New constants are added for the length limits.
Table name related code are moved into methods in TableMetadata class,
so their semantics are more clear and to allow reuse, e.g., in
asserting the table name length constant.
Tests are added for the long table names and non-alphanumeric names.
Keyspace name validation function is now shared between two classes and
a unit test of it is added.
Patch by Ruslan Fomkin; reviewed by Piotr Kołaczkowski, Dmitry
Konstantinov, Maxwell Guo for CASSANDRA-20389
patch by Caleb Rackliffe; reviewed by Marcus Eriksson for CASSANDRA-20887
Co-authored-by: Caleb Rackliffe <calebrackliffe@gmail.com>
Co-authored-by: Marcus Eriksson <marcuse@apache.org>
- Enforce a more reasonable limit on the number of included/excluded indexes
- Serialize vints rather than shorts in IndexSetSerializer
- Return Iterable from notExcluded() to avoid set creation
- Avoid redundant iteration in MessagingService#endpointsWithConnectionsOnVersionBelow()
patch by Caleb Rackliffe; reviewed by Marcus Eriksson for CASSANDRA-20888
Also Fix:
- RegisteredCallback should remove itself from callback map when cancelled
- Do not throw CancellationException when processing requests that have been aborted, as may be caused by a successful meaningful reply that can be overridden
- system_accord_debug.{executors,coordinations} fail with ClassCastException
- CommandStore.updateMinHlc eats up CPU as called much too often
- AccordCache not notifying flushed on shutdown
Also Improve:
- Support skipping Deps
- Violation information reported
- Sort CommandStore shards by id
patch by Benedict; reviewed by Aleksey Yeschenko for CASSANDRA-20896
Avoid audit batch event creation if audit for batch is not enabled (random UIID generation is not very cheap)
Avoid String.format in a potential hot path
Patch by Dmitry Konstantinov; reviewed by Štefan Miklošovič for CASSANDRA-20885
Co-authored-by: Štefan Miklošovič
Also Fix:
- JournalAndTableKeyIterator not merging in consistent order, which can lead to replaying topologies in non-ascending order
- Invariant failure when reporting topologies if fetchTopologies on startup yields a gap
- removeRedundantMissing could erroneously remove missing dependencies occurring after the new appliedBeforeIndex
- Invariant failure for some propagate calls supplying 'wrong' addRoute
- Disambiguate nextTxnId and nextTxnIdWithDefaultFlags
Also Improve:
- LocalLog should not use NoSuchElementException for control flow (instead use ConcurrentSkipListMap)
patch by Benedict; reviewed by Aleksey Yeschenko for CASSANDRA-20886
- JournalAndTableKeyIterator not merging in consistent order
- Track all active Coordinations
- Refactor Replica/Coordinator metrics and report Coordinator exhausted/preempted/timeout
- DurabilityQueue metrics and visibility
Also Fix:
- WaitingState can get cause distributed stall when asked to wait for CanApply if not yet PreCommitted; track separate querying state and advance this to the next achievable state rather than the desired final state
- Stalled coordinators should not prevent recovery
- Edge case with fetch unable to make progress when pre-bootstrap and all peers have GC'd
- Dependency initialisation for sync points across certain ownership changes
- SyncPoint propagation may not include all of the epochs required on the receiving node for ranges they have lost but not closed, and receiving node does not validate them
- Stable tracker accounting with LocalExecute
- Do not prune non-durable APPLIED as must be reported in dependencies until durably applied (so as not to break recovery)
- Ensure we cannot race with replies when initiating Coordination
- ProgressLog does not guarantee to clear home or waiting states when erased or invalidated by compaction
- WaitingState on non-home shard cannot guarantee progress once home shard is Erased
- WaitingOnSync handles retired ranges incorrectly
Also Improve:
- Standardise failure accounting, use null to represent single reply timeouts
- BurnTest record/replay to/from file
patch by Benedict; reviewed by Alex Petrov for CASSANDRA-20878
javadoc target is behaving unpredictably, sometimes fails, sometimes does not.
I strongly suspect that it just does not have enough memory available and it fails.
This is currently a blocker for releases. My empirical testing shows that more memory
we assign to javadoc generation, less probable it is it will fail to finish successfuly.
patch by Stefan Miklosovic for CASSANDRA-20868
Benedict Elliott Smith