[jira] [Commented] (CASSANDRA-16349) SSTableLoader reports error when SSTable(s) do not have data for some nodes
[
https://issues.apache.org/jira/browse/CASSANDRA-16349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17469088#comment-17469088
]
Aleksandr Sorokoumov commented on CASSANDRA-16349:
--
[~e.dimitrova] Do you have spare cycles to review this patch?
> SSTableLoader reports error when SSTable(s) do not have data for some nodes
> ---
>
> Key: CASSANDRA-16349
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16349
> Project: Cassandra
> Issue Type: Bug
> Components: Tool/sstable
>Reporter: Serban Teodorescu
>Assignee: Serban Teodorescu
>Priority: Normal
> Fix For: 4.0.x, 4.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Running SSTableLoader in verbose mode will show error(s) if there are node(s)
> that do not own any data from the SSTable(s). This can happen in at least 2
> cases:
> # SSTableLoader is used to stream backups while keeping the same token ranges
> # SSTable(s) are created with CQLSSTableWriter to match token ranges (this
> can bring better performance by using ZeroCopy streaming)
> Partial output of the SSTableLoader:
> {quote}ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47]
> Remote peer /127.0.0.4:7000 failed stream session.
> ERROR 02:47:47,842 [Stream #fa8e73b0-3da5-11eb-9c47-c5d27ae8fe47] Remote peer
> /127.0.0.3:7000 failed stream session.
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.611KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.515KiB/s)
> progress: [/127.0.0.4:7000]0:0/1 100% [/127.0.0.3:7000]0:0/1 100%
> [/127.0.0.2:7000]0:7/7 100% [/127.0.0.1:7000]0:7/7 100% total: 100%
> 0.000KiB/s (avg: 1.427KiB/s)
> {quote}
>
> Stack trace:
> {quote}java.util.concurrent.ExecutionException:
> org.apache.cassandra.streaming.StreamException: Stream failed
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:552)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:533)
> at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:99)
> at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> Caused by: org.apache.cassandra.streaming.StreamException: Stream failed
> at
> org.apache.cassandra.streaming.management.StreamEventJMXNotifier.onFailure(StreamEventJMXNotifier.java:88)
> at
> com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1056)
> at
> com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30)
> at
> com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1138)
> at
> com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:958)
> at
> com.google.common.util.concurrent.AbstractFuture.setException(AbstractFuture.java:748)
> at
> org.apache.cassandra.streaming.StreamResultFuture.maybeComplete(StreamResultFuture.java:220)
> at
> org.apache.cassandra.streaming.StreamResultFuture.handleSessionComplete(StreamResultFuture.java:196)
> at
> org.apache.cassandra.streaming.StreamSession.closeSession(StreamSession.java:505)
> at
> org.apache.cassandra.streaming.StreamSession.complete(StreamSession.java:819)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:595)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> at java.base/java.lang.Thread.run(Thread.java:844)
> {quote}
> To reproduce create a cluster with ccm with more nodes than the RF, put some
> data into it copy a SSTable and stream it.
>
> The error originates on the nodes, the following stack trace is shown in the
> logs:
> {quote}java.lang.IllegalStateException: Stream hasn't been read yet
> at
> com.google.common.base.Preconditions.checkState(Preconditions.java:507)
> at
> org.apache.cassandra.db.streaming.CassandraIncomingFile.getSize(CassandraIncomingFile.java:96)
> at
> org.apache.cassandra.streaming.StreamSession.receive(StreamSession.java:789)
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:587)
> at
> org.apache.cassandra.streaming.async.StreamingInboundHandler$StreamDeserializingTask.run(StreamingInboundHandler.java:189)
> at
>
[jira] [Updated] (CASSANDRA-17237) Pathalogical interaction between Cassandra and readahead, particularly on Centos 7 VMs
[ https://issues.apache.org/jira/browse/CASSANDRA-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Cranford updated CASSANDRA-17237: Description: Cassandra defaults to using mmap for IO, except on 32 bit systems. The config value `disk_access_mode` that controls this isn't even included in or documented in cassandra.yml. While this may be a reasonable default config for Cassandra, we've noticed a pathalogical interplay between the way Linux implements readahead for mmap, and Cassandra's IO patterns, particularly on vanilla Centos 7 VMs. A read that misses all levels of cache in Cassandra is (typically) going to involve 2 IOs: 1 into the index file and one into the data file. These IOs will both be effectively random given the nature the mummer3 hash partitioner. The amount of data read from the index file IO will be relatively small, perhaps 4-8kb, compared to the data file IO which (assuming the entire partition fits in a single compressed chunk and a compression ratio of 1/2) will require 32kb. However, applications using `mmap()` have no way to tell the OS the desired IO size - they can only tell the OS the desired IO location - by reading from the mapped address and triggering a page fault. This is unlike `read()` where the application provides both the size and location to the OS. So for `mmap()` the OS has to guess how large the IO submitted to the backing device should be and whether the application is performing sequential or random IO unless the application provides hints (eg `fadvise()`, `madvise()`, `readahead()`). This is how Linux determines the size of IO for mmap during a page fault: * Outside of hints (eg FADV_RANDOM) default IO size is maximum readahead value with the faulting address in the middle of the IO, eg IO requested for range [fault_addr - max_readahead / 2, fault_addr + max_readahead / 2] This is sometimes referred to as "read around" (ie read around the faulting address). See [here|https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2989] * The kernel maintains a cache miss counter for the file. Every time the kernel submits an IO for a page fault, this counts as a miss. Every time the application faults in a page that is already in the pages cache (presumably from a previous page fault's IO) is a cache hit and decrements the counter. If the miss counter exceeds a threshold, the kernel stops inflating the IOs to the max readahead and falls back to reading a *single* 4k page for each page fault. See summary [here|https://www.quora.com/What-heuristics-does-the-adaptive-readahead-implementation-in-the-Linux-kernel-use/answer/Robert-Love-1] and implementation [here|https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2955] and [here|https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L3005] * This means an application that, on average, references more than one 4k page around the initial page fault will consistently have page fault IOs inflated to the maximum readahead value. Note, there is no ramping up a window the way there is with standard IO. The kernel only submits IOs of 1 page and max_readahead as far as I can tell. Observations: * mmap'ed IO on Linux wastes half the IO bandwith. This may or may not be a big deal depending on your setup. * Cassandra will always have IOs inflated to the maximum readahead because more than 1 page is references for the data file and (depending on the size and cardinality of your keys) more than one page is referenced from the index file * The device's readahead is a crude system wide knob for controlling IO size. Cassandra cannot perform smaller IOs for the index file (unless your keyset is such that only 1 page from the index file needs to be referenced). Centos 7 VMs: * The default readahead for Centos 7 VMs is 4MB (as opposed to the default readahead for non-VM Centos 7 which is 128kb). * Even though this is reduced by the kernel (cf `max_sane_readahead()`) to something around 450k, it is still far too large for an average Cassandra read. * Even once this readahead is reduced to the recommended 64kb, standard IO still has a 10% performance advantage in our tests, likely because the readahead algorithm for standard IO is more flexible and converges on smaller reads from the index file and larger reads from the data file. was: Cassandra defaults to using mmap for IO, except on 32 bit systems. The config value `disk_access_mode` that controls this isn't even included in or documented in cassandra.yml. While this may be a reasonable default config for Cassandra, we've noticed a pathalogical interplay between the way Linux implements readahead for mmap, and Cassandra's IO patterns, particularly on vanilla Centos 7 VMs. A read that misses all levels of cache in Cassandra is (
[jira] [Updated] (CASSANDRA-17237) Pathalogical interaction between Cassandra and readahead, particularly on Centos 7 VMs
[ https://issues.apache.org/jira/browse/CASSANDRA-17237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Cranford updated CASSANDRA-17237: Description: Cassandra defaults to using mmap for IO, except on 32 bit systems. The config value `disk_access_mode` that controls this isn't even included in or documented in cassandra.yml. While this may be a reasonable default config for Cassandra, we've noticed a pathalogical interplay between the way Linux implements readahead for mmap, and Cassandra's IO patterns, particularly on vanilla Centos 7 VMs. A read that misses all levels of cache in Cassandra is (typically) going to involve 2 IOs: 1 into the index file and one into the data file. These IOs will both be effectively random given the nature the mummer3 hash partitioner. The amount of data read from the index file IO will be relatively small, perhaps 4-8kb, compared to the data file IO which (assuming the entire partition fits in a single compressed chunk and a compression ratio of 1/2) will require 32kb. However, applications using `mmap()` have no way to tell the OS the desired IO size - they can only tell the OS the desired IO location - by reading from the mapped address and triggering a page fault. This is unlike `read()` where the application provides both the size and location to the OS. So for `mmap()` the OS has to guess how large the IO submitted to the backing device should be and whether the application is performing sequential or random IO unless the application provides hints (eg `fadvise()`, `madvise()`, `readahead()`). This is how Linux determines the size of IO for mmap during a page fault: * Outside of hints (eg FADV_RANDOM) default IO size is maximum readahead value with the faulting address in the middle of the IO, eg IO requested for range [fault_addr - max_readahead / 2, fault_addr + max_readahead / 2] This is sometimes referred to as "read around" (ie read around the faulting address). See [here](https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2989) * The kernel maintains a cache miss counter for the file. Every time the kernel submits an IO for a page fault, this counts as a miss. Every time the application faults in a page that is already in the pages cache (presumably from a previous page fault's IO) is a cache hit and decrements the counter. If the miss counter exceeds a threshold, the kernel stops inflating the IOs to the max readahead and falls back to reading a *single* 4k page for each page fault. See summary [here|https://www.quora.com/What-heuristics-does-the-adaptive-readahead-implementation-in-the-Linux-kernel-use/answer/Robert-Love-1] and implementation [here|https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2955] and [here|https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L3005] * This means an application that, on average, references more than one 4k page around the initial page fault will consistently have page fault IOs inflated to the maximum readahead value. Note, there is no ramping up a window the way there is with standard IO. The kernel only submits IOs of 1 page and max_readahead as far as I can tell. Observations: * mmap'ed IO on Linux wastes half the IO bandwith. This may or may not be a big deal depending on your setup. * Cassandra will always have IOs inflated to the maximum readahead because more than 1 page is references for the data file and (depending on the size and cardinality of your keys) more than one page is referenced from the index file * The device's readahead is a crude system wide knob for controlling IO size. Cassandra cannot perform smaller IOs for the index file (unless your keyset is such that only 1 page from the index file needs to be referenced). Centos 7 VMs: * The default readahead for Centos 7 VMs is 4MB (as opposed to the default readahead for non-VM Centos 7 which is 128kb). * Even though this is reduced by the kernel (cf `max_sane_readahead()`) to something around 450k, it is still far too large for an average Cassandra read. * Even once this readahead is reduced to the recommended 64kb, standard IO still has a 10% performance advantage in our tests, likely because the readahead algorithm for standard IO is more flexible and converges on smaller reads from the index file and larger reads from the data file. was: Cassandra defaults to using mmap for IO, except on 32 bit systems. The config value `disk_access_mode` that controls this isn't even included in or documented in cassandra.yml. While this may be a reasonable default config for Cassandra, we've noticed a pathalogical interplay between the way Linux implements readahead for mmap, and Cassandra's IO patterns, particularly on vanilla Centos 7 VMs. A read that misses all levels of cache in Cassandra is
[jira] [Created] (CASSANDRA-17237) Pathalogical interaction between Cassandra and readahead, particularly on Centos 7 VMs
Daniel Cranford created CASSANDRA-17237: --- Summary: Pathalogical interaction between Cassandra and readahead, particularly on Centos 7 VMs Key: CASSANDRA-17237 URL: https://issues.apache.org/jira/browse/CASSANDRA-17237 Project: Cassandra Issue Type: Bug Reporter: Daniel Cranford Cassandra defaults to using mmap for IO, except on 32 bit systems. The config value `disk_access_mode` that controls this isn't even included in or documented in cassandra.yml. While this may be a reasonable default config for Cassandra, we've noticed a pathalogical interplay between the way Linux implements readahead for mmap, and Cassandra's IO patterns, particularly on vanilla Centos 7 VMs. A read that misses all levels of cache in Cassandra is (typically) going to involve 2 IOs: 1 into the index file and one into the data file. These IOs will both be effectively random given the nature the mummer3 hash partitioner. The amount of data read from the index file IO will be relatively small, perhaps 4-8kb, compared to the data file IO which (assuming the entire partition fits in a single compressed chunk and a compression ratio of 1/2) will require 32kb. However, applications using `mmap()` have no way to tell the OS the desired IO size - they can only tell the OS the desired IO location - by reading from the mapped address and triggering a page fault. This is unlike `read()` where the application provides both the size and location to the OS. So for `mmap()` the OS has to guess how large the IO submitted to the backing device should be and whether the application is performing sequential or random IO unless the application provides hints (eg `fadvise()`, `madvise()`, `readahead()`). This is how Linux determines the size of IO for mmap during a page fault: * Outside of hints (eg FADV_RANDOM) default IO size is maximum readahead value with the faulting address in the middle of the IO, eg IO requested for range [fault_addr - max_readahead / 2, fault_addr + max_readahead / 2] This is sometimes referred to as "read around" (ie read around the faulting address). See [here](https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2989) * The kernel maintains a cache miss counter for the file. Every time the kernel submits an IO for a page fault, this counts as a miss. Every time the application faults in a page that is already in the pages cache (presumably from a previous page fault's IO) is a cache hit and decrements the counter. If the miss counter exceeds a threshold, the kernel stops inflating the IOs to the max readahead and falls back to reading a *single* 4k page for each page fault. See summary [here](https://www.quora.com/What-heuristics-does-the-adaptive-readahead-implementation-in-the-Linux-kernel-use/answer/Robert-Love-1) and implementation [here](https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L2955) and [here](https://github.com/torvalds/linux/blob/0c941cf30b913d4a684d3f8d9eee60e0daffdc79/mm/filemap.c#L3005) * This means an application that, on average, references more than one 4k page around the initial page fault will consistently have page fault IOs inflated to the maximum readahead value. Note, there is no ramping up a window the way there is with standard IO. The kernel only submits IOs of 1 page and max_readahead as far as I can tell. Observations: * mmap'ed IO on Linux wastes half the IO bandwith. This may or may not be a big deal depending on your setup. * Cassandra will always have IOs inflated to the maximum readahead because more than 1 page is references for the data file and (depending on the size and cardinality of your keys) more than one page is referenced from the index file * The device's readahead is a crude system wide knob for controlling IO size. Cassandra cannot perform smaller IOs for the index file (unless your keyset is such that only 1 page from the index file needs to be referenced). Centos 7 VMs: * The default readahead for Centos 7 VMs is 4MB (as opposed to the default readahead for non-VM Centos 7 which is 128kb). * Even though this is reduced by the kernel (cf `max_sane_readahead()`) to something around 450k, it is still far too large for an average Cassandra read. * Even once this readahead is reduced to the recommended 64kb, standard IO still has a 10% performance advantage in our tests, likely because the readahead algorithm for standard IO is more flexible and converges on smaller reads from the index file and larger reads from the data file. -- 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-17160) Emit warnings for deprecated parameters (changed names) only once
[ https://issues.apache.org/jira/browse/CASSANDRA-17160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468843#comment-17468843 ] Ekaterina Dimitrova commented on CASSANDRA-17160: - [4.0 patch|https://github.com/ekaterinadimitrova2/cassandra/pull/new/17160-4.0] | [Jenkins CI run|https://jenkins-cm4.apache.org/job/Cassandra-devbranch/1345/] I will move the ticket to PATCH AVAILABLE when the CI completes to ensure I didn't break anything random. The patch is absolutely identical in trunk. I will run CI there pre-commit. In theory this part was already reviewed for CASSANDRA-15234 but not committed. As the work from CASSANDRA-15234 will be committed only to trunk, I had to backport this fix separately. > Emit warnings for deprecated parameters (changed names) only once > - > > Key: CASSANDRA-17160 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17160 > Project: Cassandra > Issue Type: Improvement > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Low > Fix For: 4.0.x > > > We added backward compatibility for two config parameters in CASSANDRA-17141 > to fix a bug but I realized that with the current setup, a warning for > deprecated parameter can be logged more than once which is not needed and > only introduces noise to the logs. > I already fixed that in CASSANDRA-15234 where this would lead to a lot of > warnings and it is easy to spot. I will backport the tiny fix here too in > case we add more parameters, etc; to prevent the potential noise. > -- 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-17234) Workaround the need to use ant script task in build.xml
[ https://issues.apache.org/jira/browse/CASSANDRA-17234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ekaterina Dimitrova updated CASSANDRA-17234: Description: In order to use ant script task in Java 17 we would need to introduce Graal js and other dependencies as Nashorn was removed. My plan is to try to workaround the usage of ant script task by creating my own custom ant tasks and not introducing new dependencies to the project. was: In order to use ant script task in Java 17 we would need to introduce Graal js and other dependencies as Nashorn was removed. My plan is to try to workaround it by creating my own custom ant tasks and not introducing new dependencies to the project. > Workaround the need to use ant script task in build.xml > --- > > Key: CASSANDRA-17234 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17234 > Project: Cassandra > Issue Type: Task > Components: Build >Reporter: Ekaterina Dimitrova >Assignee: Ekaterina Dimitrova >Priority: Normal > Fix For: 4.x > > > In order to use ant script task in Java 17 we would need to introduce Graal > js and other dependencies as Nashorn was removed. > My plan is to try to workaround the usage of ant script task by creating my > own custom ant tasks and not introducing new dependencies to the project. -- 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] [Assigned] (CASSANDRA-17224) Add a virtual table for exposing prepared statements metrics
[
https://issues.apache.org/jira/browse/CASSANDRA-17224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17224:
--
Assignee: Shailaja Koppu
> Add a virtual table for exposing prepared statements metrics
>
>
> Key: CASSANDRA-17224
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17224
> Project: Cassandra
> Issue Type: Improvement
> Components: Feature/Virtual Tables, Observability/Metrics
>Reporter: Benjamin Lerer
>Assignee: Shailaja Koppu
>Priority: Normal
> Labels: AdventCalendar2021, lhf
>
> There are some existing metrics within {{CQLMetrics}} that provide metrics
> about prepared statements. We should expose those through a virtual table.
> +Additional information for newcomers:+
> A new class should be created for representing the new Virtual Table in
> {{org.apache.cassandra.db.virtual}}. You can look at {{ThreadPoolsTable}} for
> an example.
> The new table will need to be registered in {{SystemViewsKeyspace}}.
> Some unit tests will need to be added. For some example of virtual table
> tests you can look at {{SystemPropertiesTableTest}} and for some example of
> test around prepared statement metrics you can look into {{CQLMetricsTest}}.
--
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] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: (was: Shailaja Koppu)
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: Shailaja Koppu
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Shailaja Koppu
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: (was: Shailaja Koppu)
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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] [Assigned] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shailaja Koppu reassigned CASSANDRA-17236:
--
Assignee: Shailaja Koppu
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Assignee: Shailaja Koppu
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468774#comment-17468774
]
Madhavan commented on CASSANDRA-17236:
--
It appears that Python recommends
[argparse|https://docs.python.org/2.7/library/argparse.html#module-argparse]
over optparse module going forward.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (\-\-help) and
(\-\-version) options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the (--v) option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (--help) and (--version)
options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the (\-\-v) option to spit the version info.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (--v) option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (--help) and (--version)
options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the (\-\-v) option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (\-\-help) and
(\-\-version) options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (--help) and
> (--version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the (\-\-v) option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (\-\-help) and
(\-\-version) options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (--help) and (--version)
options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (\-\-help) and
> (\-\-version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the {{-v}} option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both (--help) and (--version)
options are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both
--{{{}{{{}help{}}}{-}{-}{}}} and {{--version}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both (--help) and
> (--version) options are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the {{-v}} option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both {{-{-}help{-}}} and
{{-version-}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string|https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{}}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
{{}}
{{}}
This looks like a weird implementation at Python. Both {{--help}} and
{{--version}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{--v}} option to spit the version info.{{{}{}}}
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both {{-{-}help{-}}} and
> {{-version-}} are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the {{-v}} option to spit the version info.
--
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...@cassandr
[jira] [Updated] (CASSANDRA-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both
--{{{}{{{}help{}}}{-}{-}{}}} and {{--version}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
was:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
This looks like a weird implementation at Python. Both {{-{-}help{-}}} and
{{-version-}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{-v}} option to spit the version info.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
>
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> This looks like a weird implementation at Python. Both
> --{{{}{{{}help{}}}{-}{-}{}}} and {{--version}} are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the {{-v}} option to spit the version info.
--
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-17236) Add support for short form of version to CQLSH
[
https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Madhavan updated CASSANDRA-17236:
-
Description:
Today we do only support the `–version` long option/form for cqlsh and this
enhancement Jira is to request that we also offer a shorter version `-v` to
cqlsh. This will have consistency benefits with other tools and even match with
what we have at `bin/cassandra -v` option for instance.
Today, `cqlsh` does support `--v` to get the version which is different than
the single dashed short form that is available at many other tools. Thanks to
Ekaterina for finding this. It looks like this is stemming from Python's parse
mechanism which is detailed here,
[https://docs.python.org/2.7/library/optparse.html#printing-a-version-string|https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
[https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
{quote}parser = optparse.OptionParser(description=description, epilog=epilog,
usage="Usage: %prog [options] [host [port]]",
version='cqlsh ' + version)
{quote}
{{}}
{{$ bin/cqlsh --v}}
{{cqlsh 6.0.0}}
{{}}
{{}}
This looks like a weird implementation at Python. Both {{--help}} and
{{--version}} are stemming from here,
[https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
they did decide to ignore the short form option for version and it somehow
automatically takes the {{--v}} option to spit the version info.{{{}{}}}
was:Today we do only support the `–version` long option/form for cqlsh and
this enhancement Jira is to request that we also offer a shorter version `-v`
to cqlsh. This will have consistency benefits with other tools and even match
with what we have at `bin/cassandra -v` option for instance.
> Add support for short form of version to CQLSH
> --
>
> Key: CASSANDRA-17236
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17236
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL/Semantics
>Reporter: Madhavan
>Priority: Low
> Labels: lhf
> Fix For: 4.x
>
>
> Today we do only support the `–version` long option/form for cqlsh and this
> enhancement Jira is to request that we also offer a shorter version `-v` to
> cqlsh. This will have consistency benefits with other tools and even match
> with what we have at `bin/cassandra -v` option for instance.
> Today, `cqlsh` does support `--v` to get the version which is different than
> the single dashed short form that is available at many other tools. Thanks to
> Ekaterina for finding this. It looks like this is stemming from Python's
> parse mechanism which is detailed here,
> [https://docs.python.org/2.7/library/optparse.html#printing-a-version-string|https://docs.python.org/2.7/library/optparse.html#printing-a-version-string].
>
> [https://github.com/apache/cassandra/blob/trunk/bin/cqlsh.py#L194-L196]
> {quote}parser = optparse.OptionParser(description=description, epilog=epilog,
> usage="Usage: %prog [options] [host [port]]",
> version='cqlsh ' + version)
> {quote}
> {{}}
> {{$ bin/cqlsh --v}}
> {{cqlsh 6.0.0}}
> {{}}
> {{}}
> This looks like a weird implementation at Python. Both {{--help}} and
> {{--version}} are stemming from here,
> [https://github.com/python/cpython/blob/2.7/Lib/optparse.py#L1248-L1256] and
> they did decide to ignore the short form option for version and it somehow
> automatically takes the {{--v}} option to spit the version info.{{{}{}}}
--
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-17236) Add support for short form of version to CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Madhavan updated CASSANDRA-17236: - Description: Today we do only support the `–version` long option/form for cqlsh and this enhancement Jira is to request that we also offer a shorter version `-v` to cqlsh. This will have consistency benefits with other tools and even match with what we have at `bin/cassandra -v` option for instance. (was: Today we do only support the `–version` option/form for cqlsh and this enhancement Jira is to request that we also offer a shorter version `-v` to cqlsh. This will have consistency benefits with other tools and even match with what we have at `bin/cassandra -v` option for instance.) > Add support for short form of version to CQLSH > -- > > Key: CASSANDRA-17236 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17236 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Madhavan >Priority: Low > Labels: lhf > Fix For: 4.x > > > Today we do only support the `–version` long option/form for cqlsh and this > enhancement Jira is to request that we also offer a shorter version `-v` to > cqlsh. This will have consistency benefits with other tools and even match > with what we have at `bin/cassandra -v` option for instance. -- 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-17236) Add support for short form of version to CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17236: - Labels: lhf (was: ) > Add support for short form of version to CQLSH > -- > > Key: CASSANDRA-17236 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17236 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Madhavan >Priority: Low > Labels: lhf > Fix For: 4.x > > > Today we do only support the `–version` option/form for cqlsh and this > enhancement Jira is to request that we also offer a shorter version `-v` to > cqlsh. This will have consistency benefits with other tools and even match > with what we have at `bin/cassandra -v` option for instance. -- 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-17236) Add support for short form of version to CQLSH
[ https://issues.apache.org/jira/browse/CASSANDRA-17236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Williams updated CASSANDRA-17236: - Change Category: Operability Complexity: Low Hanging Fruit Fix Version/s: 4.x Priority: Low (was: Normal) Status: Open (was: Triage Needed) > Add support for short form of version to CQLSH > -- > > Key: CASSANDRA-17236 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17236 > Project: Cassandra > Issue Type: Improvement > Components: CQL/Semantics >Reporter: Madhavan >Priority: Low > Fix For: 4.x > > > Today we do only support the `–version` option/form for cqlsh and this > enhancement Jira is to request that we also offer a shorter version `-v` to > cqlsh. This will have consistency benefits with other tools and even match > with what we have at `bin/cassandra -v` option for instance. -- 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-17236) Add support for short form of version to CQLSH
Madhavan created CASSANDRA-17236: Summary: Add support for short form of version to CQLSH Key: CASSANDRA-17236 URL: https://issues.apache.org/jira/browse/CASSANDRA-17236 Project: Cassandra Issue Type: Improvement Components: CQL/Semantics Reporter: Madhavan Today we do only support the `–version` option/form for cqlsh and this enhancement Jira is to request that we also offer a shorter version `-v` to cqlsh. This will have consistency benefits with other tools and even match with what we have at `bin/cassandra -v` option for instance. -- 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-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Sorokoumov updated CASSANDRA-15215: - Reviewers: Benedict Elliott Smith, Branimir Lambov (was: Benedict Elliott Smith) > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: testWriteRandomLongDOP_final.png, > writeUnsignedVInt_megamorphic_BB.png, writeUnsignedVInt_megamorphic_DOP.png > > Time Spent: 40m > Remaining Estimate: 0h > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- 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-15215) VIntCoding should read and write more efficiently
[ https://issues.apache.org/jira/browse/CASSANDRA-15215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468706#comment-17468706 ] Aleksandr Sorokoumov commented on CASSANDRA-15215: -- I added [~blambov] as a reviewer as he approved the PR to trunk. [~benedict] is there anything I can do to facilitate the merge? > VIntCoding should read and write more efficiently > - > > Key: CASSANDRA-15215 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15215 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable >Reporter: Benedict Elliott Smith >Assignee: Aleksandr Sorokoumov >Priority: Normal > Fix For: 3.0.x, 3.11.x, 4.x > > Attachments: testWriteRandomLongDOP_final.png, > writeUnsignedVInt_megamorphic_BB.png, writeUnsignedVInt_megamorphic_DOP.png > > Time Spent: 40m > Remaining Estimate: 0h > > Most vints occupy significantly fewer than 8 bytes, and most buffers have >= > 8 bytes spare, in which case we can construct the relevant bytes in a > register and memcpy them to the correct position. Since we read and write a > lot of vints, this waste is probably measurable, particularly during > compaction and flush, and can probably be considered a performance bug. -- 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-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468696#comment-17468696
]
Ekaterina Dimitrova commented on CASSANDRA-17182:
-
Thank you [~jmckenzie], I plan to update the docs these days. Mick just
mentioned he is about to merge the asciidoc and we can start updating in the
new format. That's my plan.
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
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-17207) The process cannot access the file because it is being used by another process.
[
https://issues.apache.org/jira/browse/CASSANDRA-17207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468694#comment-17468694
]
Josh McKenzie commented on CASSANDRA-17207:
---
Gotcha [~shravan001]. I fall back on the:
{quote}This is usually because you're on Windows and something else has a
handle open to the file; you can't delete files (or hard links, thanks NTFS) on
Windows if someone has a handle open to it.
{quote}
Consider trying a utility like
[handle|https://docs.microsoft.com/en-us/sysinternals/downloads/handle] from
sysinternals to figure out what else has a handle open to that file that's
preventing its deletion. Worst-case it'll be the java process, and thus C*,
that have a different handle open to the file and we'll be stuck in the
"Cassandra isn't really formally supported on Windows" territory.
Since this is CommitLog segment deletion your risk is the drive filling up due
to these segments not being appropriately de-allocated and deleted.
> The process cannot access the file because it is being used by another
> process.
> ---
>
> Key: CASSANDRA-17207
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17207
> Project: Cassandra
> Issue Type: Bug
>Reporter: shravansingh
>Priority: Normal
>
>
> ERROR [COMMIT-LOG-ALLOCATOR] 2021-12-11 17:02:00,989
> JVMStabilityInspector.java:140 - JVM state determined to be unstable.
> Exiting forcefully due to:
> org.apache.cassandra.io.FSWriteError: java.nio.file.FileSystemException:
> \commitlog\CommitLog-6-1636406548826.log: The process cannot access
> the file because it is being used by another process.
>
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:138)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:155)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.commitlog.CommitLogSegment.discard(CommitLogSegment.java:342)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager$2.run(CommitLogSegmentManager.java:379)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.db.commitlog.CommitLogSegmentManager$1.runMayThrow(CommitLogSegmentManager.java:156)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at
> org.apache.cassandra.concurrent.NamedThreadFactory.lambda$threadLocalDeallocator$0(NamedThreadFactory.java:79)
> [apache-cassandra-3.0.14.jar:3.0.14]
> at java.lang.Thread.run(Unknown Source) ~[na:1.8.0_301]
> Caused by: java.nio.file.FileSystemException:
> \commitlog\CommitLog-6-1636406548826.log: The process cannot access
> the file because it is being used by another process.
>
> at sun.nio.fs.WindowsException.translateToIOException(Unknown Source)
> ~[na:1.8.0_301]
> at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
> ~[na:1.8.0_301]
> at sun.nio.fs.WindowsException.rethrowAsIOException(Unknown Source)
> ~[na:1.8.0_301]
> at sun.nio.fs.WindowsFileSystemProvider.implDelete(Unknown Source)
> ~[na:1.8.0_301]
> at sun.nio.fs.AbstractFileSystemProvider.delete(Unknown Source)
> ~[na:1.8.0_301]
> at java.nio.file.Files.delete(Unknown Source) ~[na:1.8.0_301]
> at
> org.apache.cassandra.io.util.FileUtils.deleteWithConfirm(FileUtils.java:132)
> ~[apache-cassandra-3.0.14.jar:3.0.14]
> ... 7 common frames omitted
> It seems similar to https://issues.apache.org/jira/browse/CASSANDRA-8390, but
> it was resolved in 2.2 beta, though I am facing this in version 3.0.14
> I am running this on windows server OS and in cassandra.yaml,
> disk_access_mode is set to standard
--
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-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468691#comment-17468691
]
Josh McKenzie commented on CASSANDRA-17182:
---
I'll take review on this. I have a ticket that's been stalled on needing to do
this for a bit anyway. :)
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
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-17182) Add info how to test with your own CCM branch
[
https://issues.apache.org/jira/browse/CASSANDRA-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh McKenzie updated CASSANDRA-17182:
--
Reviewers: Josh McKenzie
> Add info how to test with your own CCM branch
> -
>
> Key: CASSANDRA-17182
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17182
> Project: Cassandra
> Issue Type: Task
> Components: Documentation/Website
>Reporter: Ekaterina Dimitrova
>Assignee: Ekaterina Dimitrova
>Priority: Low
>
> In CASSANDRA-16688 we solved an issue with ccm and retagging.
> It required to remove the -e from the beginning of [this
> row|https://github.com/apache/cassandra-dtest/blob/trunk/requirements.txt#L9]
> But now if someone wants to test with their own ccm branch, they need to add
> back the -e during testing so that pip3 updates with their branch. Without
> it, it doesn't update.
> *Example:*
> {code:java}
> git+https://github.com/riptano/ccm.git@cassandra-test#egg=ccm
> {code}
> This is important information and I think we need to add it to at least:
> - our Testing page where dtest runs are mentioned on the website
> - Add a comment in requirements.txt in the dtest repo
> We can also update the README files of CCM and DTests but then if something
> changes we will need to update this info in 4 places which doesn't seem
> efficient to me.
--
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-17233) Fix org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage
[ https://issues.apache.org/jira/browse/CASSANDRA-17233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468689#comment-17468689 ] Josh McKenzie commented on CASSANDRA-17233: --- ping [~yifanc] as assignee and me as reviewer; think we broke this in CASSANDRA-17002 > Fix > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage > --- > > Key: CASSANDRA-17233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17233 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > > Fails consistently on trunk: > https://ci-cassandra.apache.org/job/Cassandra-trunk/893/testReport/junit/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testNonblockingShouldMaintainSteadyDiskUsage/history/ -- 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-17233) Fix org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage
[ https://issues.apache.org/jira/browse/CASSANDRA-17233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie updated CASSANDRA-17233: -- Reviewers: Josh McKenzie > Fix > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage > --- > > Key: CASSANDRA-17233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17233 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > > Fails consistently on trunk: > https://ci-cassandra.apache.org/job/Cassandra-trunk/893/testReport/junit/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testNonblockingShouldMaintainSteadyDiskUsage/history/ -- 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] [Assigned] (CASSANDRA-17233) Fix org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage
[ https://issues.apache.org/jira/browse/CASSANDRA-17233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh McKenzie reassigned CASSANDRA-17233: - Assignee: Yifan Cai > Fix > org.apache.cassandra.db.commitlog.CommitLogSegmentManagerCDCTest.testNonblockingShouldMaintainSteadyDiskUsage > --- > > Key: CASSANDRA-17233 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17233 > Project: Cassandra > Issue Type: Bug > Components: CI >Reporter: Ekaterina Dimitrova >Assignee: Yifan Cai >Priority: Normal > Fix For: 4.x > > > Fails consistently on trunk: > https://ci-cassandra.apache.org/job/Cassandra-trunk/893/testReport/junit/org.apache.cassandra.db.commitlog/CommitLogSegmentManagerCDCTest/testNonblockingShouldMaintainSteadyDiskUsage/history/ -- 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-17231) Upgrade cassandra-driver-core to 4.X
[ https://issues.apache.org/jira/browse/CASSANDRA-17231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17468670#comment-17468670 ] Josh McKenzie commented on CASSANDRA-17231: --- The 4.x driver has (as I understand it second hand) API breaking changes in it that have sweeping consequences for many things written to the 3.x driver. Perhaps we should first look to an update to the deps in the bundled driver to a non-vulnerable version of the jackson-databind lib. > Upgrade cassandra-driver-core to 4.X > > > Key: CASSANDRA-17231 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17231 > Project: Cassandra > Issue Type: Bug > Components: Dependencies >Reporter: Phyllis Li >Assignee: Phyllis Li >Priority: Normal > Labels: security > Fix For: 4.x > > > The current Cassandra driver version is 3.11.0, which uses a vulnerable > version of jackson-databind. > We may want to switch to the re-branded com.datastax.oss:java-driver-core > 4.13.0. -- 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-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Test and Documentation Plan: (was: PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events&filter=all) PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events&filter=all > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- 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-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Test and Documentation Plan: PR: https://github.com/apache/cassandra/pull/1375 CI: https://app.circleci.com/pipelines/github/spodkowinski/cassandra?branch=unavail_events&filter=all Status: Patch Available (was: Open) > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- 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-17235) Add diagnostic events for unavailable errors
[ https://issues.apache.org/jira/browse/CASSANDRA-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Podkowinski updated CASSANDRA-17235: --- Change Category: Operability Complexity: Normal Status: Open (was: Triage Needed) > Add diagnostic events for unavailable errors > > > Key: CASSANDRA-17235 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 > Project: Cassandra > Issue Type: New Feature > Components: Observability/JMX >Reporter: Stefan Podkowinski >Assignee: Stefan Podkowinski >Priority: Normal > > Errors from unavailables during query execution lack important details on the > context why the error occurred. Emitting diagnostic events on unavailables > will allow you to attach to the instance during troubleshooting and observe > the type of operation (what kind of reads/writes), keyspace replication > settings and down nodes as seen by the instance throwing the error. -- 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-17235) Add diagnostic events for unavailable errors
Stefan Podkowinski created CASSANDRA-17235: -- Summary: Add diagnostic events for unavailable errors Key: CASSANDRA-17235 URL: https://issues.apache.org/jira/browse/CASSANDRA-17235 Project: Cassandra Issue Type: New Feature Components: Observability/JMX Reporter: Stefan Podkowinski Assignee: Stefan Podkowinski Errors from unavailables during query execution lack important details on the context why the error occurred. Emitting diagnostic events on unavailables will allow you to attach to the instance during troubleshooting and observe the type of operation (what kind of reads/writes), keyspace replication settings and down nodes as seen by the instance throwing the error. -- 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-17188) Guardrails for consistency levels
[
https://issues.apache.org/jira/browse/CASSANDRA-17188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andres de la Peña updated CASSANDRA-17188:
--
Change Category: Operability
Complexity: Normal
Status: Open (was: Triage Needed)
> Guardrails for consistency levels
> -
>
> Key: CASSANDRA-17188
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17188
> Project: Cassandra
> Issue Type: New Feature
> Components: Feature/Guardrails
>Reporter: Andres de la Peña
>Assignee: Andres de la Peña
>Priority: Normal
>
> Add guardrails for read/write consistency levels, for example:
> {code:java}
> # Guardrail to warn about or reject read consistency levels.
> # By default all consistency levels are allowed.
> read_consistency_levels:
> warned: []
> disallowed: []
> # Guardrail to warn about or reject write consistency levels.
> # By default all consistency levels are allowed.
> write_consistency_levels:
> warned: []
> disallowed: []
> {code}
--
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
