[jira] [Commented] (CASSANDRA-11695) Move JMX connection config to cassandra.yaml
[ https://issues.apache.org/jira/browse/CASSANDRA-11695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464216#comment-15464216 ] Zhongxiang Zheng commented on CASSANDRA-11695: -- Thanks for reviewing and fixing! I think changes are good. I agree with your opinion that settings in the yaml should not override with system properties. > Move JMX connection config to cassandra.yaml > > > Key: CASSANDRA-11695 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11695 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Sam Tunnicliffe >Assignee: Zhongxiang Zheng >Priority: Minor > Labels: lhf > Fix For: 3.x > > > Since CASSANDRA-10091, we always construct the JMX connector server > programatically, so we could move its configuration from cassandra-env to > yaml. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9033) Upgrading from 2.1.1 to 2.1.3 with LCS and many sstable files makes nodes unresponsive
[
https://issues.apache.org/jira/browse/CASSANDRA-9033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Deng updated CASSANDRA-9033:
Labels: (was: lcs)
> Upgrading from 2.1.1 to 2.1.3 with LCS and many sstable files makes nodes
> unresponsive
> ---
>
> Key: CASSANDRA-9033
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9033
> Project: Cassandra
> Issue Type: Bug
> Environment: * Ubuntu 14.04.2 - Linux ip-10-0-2-122 3.13.0-46-generic
> #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> * EC2 m2-xlarge instances [4cpu, 16GB RAM, 1TB storage on 3 platters]
> * 12 nodes running a mix of 2.1.1 and 2.1.3
> * 8GB stack size with offheap objects
>Reporter: Brent Haines
>Assignee: Marcus Eriksson
> Attachments: cassandra-env.sh, cassandra.yaml, system.log.1.zip
>
>
> We have an Event Log table using LCS that has grown fast. There are more than
> 100K sstable files that are around 1KB. Increasing compactors and adjusting
> compaction throttling upward doesn't make a difference. It has been running
> great though until we upgraded to 2.1.3. Those nodes needed more RAM for the
> stack (12 GB) to even have a prayer of responding to queries. They bog down
> and become unresponsive. There are no GC messages that I can see, and no
> compaction either.
> The only work-around I have found is to decommission, blow away the big CF
> and rejoin. That happens in about 20 minutes and everything is freaking happy
> again. The size of the files is more like what I'd expect as well.
> Our schema:
> {code}
> cqlsh> describe columnfamily data.stories
> CREATE TABLE data.stories (
> id timeuuid PRIMARY KEY,
> action_data timeuuid,
> action_name text,
> app_id timeuuid,
> app_instance_id timeuuid,
> data map,
> objects set,
> time_stamp timestamp,
> user_id timeuuid
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
> AND comment = 'Stories represent the timeline and are placed in the
> dashboard for the brand manager to see'
> AND compaction = {'min_threshold': '4', 'class':
> 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy',
> 'max_threshold': '32'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> cqlsh>
> {code}
> There were no log entries that stood out. It pretty much consisted of "x is
> down" "x is up" repeated ad infinitum. I have attached the zipped system.log
> that has the situation after the upgrade and then after I stopped, removed
> system, system_traces, OpsCenter, and data/stories-/* and restarted.
> It has rejoined the cluster now and is busy read-repairing to recover its
> data.
> On another note, we see a lot of this during repair now (on all the nodes):
> {code}
> ERROR [AntiEntropySessions:5] 2015-03-24 20:03:10,207 RepairSession.java:303
> - [repair #c5043c40-d260-11e4-a2f2-8bb3e2bbdb35] session completed with the
> following error
> java.io.IOException: Failed during snapshot creation.
> at
> org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
> ~[apache-cassandra-2.1.3.jar:2.1.3]
> at
> org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:146)
> ~[apache-cassandra-2.1.3.jar:2.1.3]
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> ~[guava-16.0.jar:na]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_55]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_55]
> ERROR [AntiEntropySessions:5] 2015-03-24 20:03:10,208
> CassandraDaemon.java:167 - Exception in thread
> Thread[AntiEntropySessions:5,5,RMI Runtime]
> java.lang.RuntimeException: java.io.IOException: Failed during snapshot
> creation.
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> ~[apache-cassandra-2.1.3.jar:2.1.3]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_55]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_55]
> at
> java.util.concurrent.ThreadPoolExecutor.runWork
[jira] [Created] (CASSANDRA-12611) Allow UDFs to be used in predicates
Jon Haddad created CASSANDRA-12611:
--
Summary: Allow UDFs to be used in predicates
Key: CASSANDRA-12611
URL: https://issues.apache.org/jira/browse/CASSANDRA-12611
Project: Cassandra
Issue Type: Improvement
Reporter: Jon Haddad
Now that allow filtering can be used more liberally, it would be nice to be
able to apply a function as a predicate. For instance, if I store a bloom
filter on each row, it would be useful to be able to pass a value and a field
into a function to check if the value is possibly in the set of values the
bloom filter has seen. For example:
CREATE OR REPLACE FUNCTION inBloom (input int, field field) CALLED ON NULL
INPUT RETURNS boolean LANGUAGE java AS 'return true;'; // pretend this actual
evaluates correctly
As far as I can tell, there's no way to pass inputs to a function referencing
a field, and no way to use the result of the function in a predicate. The
following simple example fails:
cqlsh:tutorials> CREATE OR REPLACE FUNCTION inBloom (input int) CALLED ON
NULL INPUT RETURNS boolean LANGUAGE java AS 'return true;';
cqlsh:tutorials> select * from user where inBloom(1) = True;
SyntaxException: line 1:32 no viable alternative at input '(' (select * from
user where [inBloom](...)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12611) Allow UDFs to be used in predicates
[
https://issues.apache.org/jira/browse/CASSANDRA-12611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Haddad updated CASSANDRA-12611:
---
Description:
Now that allow filtering can be used more liberally, it would be nice to be
able to apply a function as a predicate. For instance, if I store a bloom
filter on each row, it would be useful to be able to pass a value and a field
into a function to check if the value is possibly in the set of values the
bloom filter has seen. For example:
{code}CREATE OR REPLACE FUNCTION inBloom (input int, field field) CALLED ON
NULL INPUT RETURNS boolean LANGUAGE java AS 'return true;'; // pretend this
actual evaluates correctly
{code}
As far as I can tell, there's no way to pass inputs to a function referencing
a field, and no way to use the result of the function in a predicate. The
following simple example fails:
{code}
cqlsh:tutorials> CREATE OR REPLACE FUNCTION inBloom (input int) CALLED ON NULL
INPUT RETURNS boolean LANGUAGE java AS 'return true;';
cqlsh:tutorials> select * from user where inBloom(1) = True;
SyntaxException: line 1:32 no viable alternative at input '(' (select * from
user where [inBloom](...)
{code}
was:
Now that allow filtering can be used more liberally, it would be nice to be
able to apply a function as a predicate. For instance, if I store a bloom
filter on each row, it would be useful to be able to pass a value and a field
into a function to check if the value is possibly in the set of values the
bloom filter has seen. For example:
CREATE OR REPLACE FUNCTION inBloom (input int, field field) CALLED ON NULL
INPUT RETURNS boolean LANGUAGE java AS 'return true;'; // pretend this actual
evaluates correctly
As far as I can tell, there's no way to pass inputs to a function referencing
a field, and no way to use the result of the function in a predicate. The
following simple example fails:
cqlsh:tutorials> CREATE OR REPLACE FUNCTION inBloom (input int) CALLED ON
NULL INPUT RETURNS boolean LANGUAGE java AS 'return true;';
cqlsh:tutorials> select * from user where inBloom(1) = True;
SyntaxException: line 1:32 no viable alternative at input '(' (select * from
user where [inBloom](...)
> Allow UDFs to be used in predicates
> ---
>
> Key: CASSANDRA-12611
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12611
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jon Haddad
>
> Now that allow filtering can be used more liberally, it would be nice to be
> able to apply a function as a predicate. For instance, if I store a bloom
> filter on each row, it would be useful to be able to pass a value and a field
> into a function to check if the value is possibly in the set of values the
> bloom filter has seen. For example:
> {code}CREATE OR REPLACE FUNCTION inBloom (input int, field field) CALLED ON
> NULL INPUT RETURNS boolean LANGUAGE java AS 'return true;'; // pretend this
> actual evaluates correctly
> {code}
> As far as I can tell, there's no way to pass inputs to a function
> referencing a field, and no way to use the result of the function in a
> predicate. The following simple example fails:
> {code}
> cqlsh:tutorials> CREATE OR REPLACE FUNCTION inBloom (input int) CALLED ON
> NULL INPUT RETURNS boolean LANGUAGE java AS 'return true;';
> cqlsh:tutorials> select * from user where inBloom(1) = True;
> SyntaxException: line 1:32 no viable alternative at input '(' (select * from
> user where [inBloom](...)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8780) cassandra-stress should support multiple table operations
[ https://issues.apache.org/jira/browse/CASSANDRA-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15463920#comment-15463920 ] Ben Slater edited comment on CASSANDRA-8780 at 9/5/16 4:38 AM: --- I've attached a patch that implements this. Key points: - existing command lines, spec files, etc should work unchanged - to test multiple files: - put a comma separated list of files names for spec= (eg spec=file1.txt,spec=file2.txt) - when specifying operations, qualify with keyspace and table name (eg ops(stressexample.eventsrawtest.insert=1,stressexample.eventsrawtest2.insert=1,stressexample.eventsrawtest2.get-a-value=1,stressexample.eventsrawtest2.pull-for-rollup=1) ) - I looked at doing unit tests but couldn't really see a way of testing without building framework for a whole lot of existing functionality I've tested a few different scenarios on files I had lying around and all seems to work. was (Author: slater_ben): I've attached a patch that implements this. Key points: - existing command lines, spec files, etc should work unchanged - to test multiple files: - put a comma separated list of files names for spec= (eg spec=file1.txt,spec=file2.txt) - when specifying operations, qualify with keyspace and table name (eg ops(stressexample.eventsrawtest.insert=1,stressexample.eventsrawtest2.insert=1,stressexample.eventsrawtest2.get-a-value=1,stressexample.eventsrawtest2.pull-for-rollup=1) ) I've tested a few different scenarios on files I had lying around and all seems to work. > cassandra-stress should support multiple table operations > - > > Key: CASSANDRA-8780 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8780 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Ben Slater > Labels: stress > Fix For: 3.x > > Attachments: 8780-trunk.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-12500) Counter cache hit counter not incrementing
[
https://issues.apache.org/jira/browse/CASSANDRA-12500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeff Jirsa resolved CASSANDRA-12500.
Resolution: Invalid
Finally got around to reading the code, and you're right -
{{ColumnFamilyStore.getCachedCounter}} is only called by {{CounterMutation}} on
update, not on the read path, so it's not a bug. Sorta surprised it's not used
on the read path, but there's (clearly) a lot I don't know about the counter
paths, so probably a good reason it's not used.
> Counter cache hit counter not incrementing
> ---
>
> Key: CASSANDRA-12500
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12500
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Priority: Minor
>
> Trivial repro on 3.7 with scripts below. Haven't dug through
> {{CounterCacheTest}} to find out if the cache is getting skipped or if it's
> just not updating the hit counter properly:
> {code}
> #!/bin/sh
> ccm remove test
> ccm create test -v 3.7 -n 1
> sed -i'' -e 's/row_cache_size_in_mb: 0/row_cache_size_in_mb: 100/g'
> .ccm/test/node1/conf/cassandra.yaml
> ccm start
> sleep 5
> ccm node1 cqlsh < ~/keyspace.cql
> ccm node1 cqlsh < ~/table-counter.cql
> ccm node1 cqlsh < ~/table-counter-clustering.cql
> echo "Schema created, reads and writes starting"
> ccm node1 nodetool info | grep Cache
> echo "UPDATE test.test SET v=v+1 WHERE id=1; " | ccm node1 cqlsh
> echo "UPDATE test.test2 SET v=v+1 WHERE id=1 and c=1; " | ccm node1 cqlsh
> echo "UPDATE test.test2 SET v=v+1 WHERE id=1 and c=2; " | ccm node1 cqlsh
> echo "SELECT * FROM test.test WHERE id=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> echo "SELECT * FROM test.test WHERE id=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> echo "SELECT * FROM test.test2 WHERE id=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> echo "SELECT * FROM test.test2 WHERE id=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> echo "SELECT * FROM test.test2 WHERE id=1 and c=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> echo "SELECT * FROM test.test2 WHERE id=1 and c=1; " | ccm node1 cqlsh
> ccm node1 nodetool info | grep Cache
> {code}
> Keyspace / tables:
> {code}
> CREATE KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '1'} AND durable_writes = true;
> {code}
> {code}
> CREATE TABLE test.test (
> id int PRIMARY KEY,
> v counter
> ) WITH caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};
> {code}
> {code}
> CREATE TABLE test.test2 (
> id int,
> c int,
> v counter,
> PRIMARY KEY(id, c)
> ) WITH caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'};
> {code}
> Output:
> {code}
> Schema created, reads and writes starting
> Key Cache : entries 17, size 1.29 KiB, capacity 24 MiB, 61 hits,
> 84 requests, 0.726 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 0, size 0 bytes, capacity 12 MiB, 0 hits, 0
> requests, NaN recent hit rate, 7200 save period in seconds
> Chunk Cache: entries 14, size 896 KiB, capacity 91 MiB, 38
> misses, 227 requests, 0.833 recent hit rate, 80.234 microseconds miss latency
> id | v
> +---
> 1 | 1
> (1 rows)
> Key Cache : entries 17, size 1.29 KiB, capacity 24 MiB, 70 hits,
> 93 requests, 0.753 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 3, size 328 bytes, capacity 12 MiB, 0 hits,
> 3 requests, 0.000 recent hit rate, 7200 save period in seconds
> Chunk Cache: entries 14, size 896 KiB, capacity 91 MiB, 38
> misses, 288 requests, 0.868 recent hit rate, 80.234 microseconds miss latency
> id | v
> +---
> 1 | 1
> (1 rows)
> Key Cache : entries 17, size 1.29 KiB, capacity 24 MiB, 72 hits,
> 95 requests, 0.758 recent hit rate, 14400 save period in seconds
> Row Cache : entries 0, size 0 bytes, capacity 100 MiB, 0 hits, 0
> requests, NaN recent hit rate, 0 save period in seconds
> Counter Cache : entries 3, size 328 bytes, capacity 12 MiB, 0 hits,
> 3 requests, 0.000 recent hit rate, 7200 save period in seconds
> Chunk Cache: entries 14, size 896 KiB, capacity 91 MiB, 38
> misses, 303 requests, 0.875 recent hit rate, 80.234 microseconds miss latency
> id | c | v
> +---+---
> 1 | 1 | 1
> 1 | 2 | 1
> (2 rows)
> Key Cache : entries 17, size 1.29 KiB, capacity 24 MiB, 74 hits,
> 97 requests, 0.763 recent hit rate, 14400 save period in
[jira] [Created] (CASSANDRA-12610) Introduce a mixed write + compact mode for compaction-stress to simulate more realistic workload
Wei Deng created CASSANDRA-12610:
Summary: Introduce a mixed write + compact mode for
compaction-stress to simulate more realistic workload
Key: CASSANDRA-12610
URL: https://issues.apache.org/jira/browse/CASSANDRA-12610
Project: Cassandra
Issue Type: Improvement
Components: Compaction
Reporter: Wei Deng
The new offline stress utility {{compaction-stress}} was introduced in
CASSANDRA-11844 which greatly simplified the amount of work needed to perform a
compaction experiment. However, it currently only provides two modes {{write}}
and {{compact}}, which means the user will always have to use {{write}} to
generate a bunch of SSTables first, and then use {{compact}} to compact them
using desired compaction strategy. This is not as close to the real workload as
possible where new SSTable writing and compaction can often happen
simultaneously which puts a different strain on CPU and IO than the current
test pattern.
With the introduction of the mixed (write / compact) mode proposed in this
JIRA, we should at least allow parameters to specify how big each newly-written
SSTable is (already supported by {{buffer-size-mb}}), and how frequently the
write happens (this is the most straightforward way to simulate a memtable
flush and might over-simplify the flush behavior, but should be easier to
implement; the more sophisticated SSTable write behavior probably can be done
in a follow-up JIRA), and allow specifying how many threads allocated to
{{write}} and {{compact}} respectively.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8780) cassandra-stress should support multiple table operations
[ https://issues.apache.org/jira/browse/CASSANDRA-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Slater updated CASSANDRA-8780: -- Attachment: 8780-trunk.patch Actually attaching the patch this time. > cassandra-stress should support multiple table operations > - > > Key: CASSANDRA-8780 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8780 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Ben Slater > Labels: stress > Fix For: 3.x > > Attachments: 8780-trunk.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8780) cassandra-stress should support multiple table operations
[ https://issues.apache.org/jira/browse/CASSANDRA-8780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ben Slater updated CASSANDRA-8780: -- Assignee: Ben Slater Fix Version/s: 3.x Status: Patch Available (was: Open) I've attached a patch that implements this. Key points: - existing command lines, spec files, etc should work unchanged - to test multiple files: - put a comma separated list of files names for spec= (eg spec=file1.txt,spec=file2.txt) - when specifying operations, qualify with keyspace and table name (eg ops(stressexample.eventsrawtest.insert=1,stressexample.eventsrawtest2.insert=1,stressexample.eventsrawtest2.get-a-value=1,stressexample.eventsrawtest2.pull-for-rollup=1) ) I've tested a few different scenarios on files I had lying around and all seems to work. > cassandra-stress should support multiple table operations > - > > Key: CASSANDRA-8780 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8780 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Benedict >Assignee: Ben Slater > Labels: stress > Fix For: 3.x > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12526) For LCS, single SSTable up-level is handled inefficiently
[
https://issues.apache.org/jira/browse/CASSANDRA-12526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wei Deng updated CASSANDRA-12526:
-
Issue Type: Improvement (was: Bug)
> For LCS, single SSTable up-level is handled inefficiently
> -
>
> Key: CASSANDRA-12526
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12526
> Project: Cassandra
> Issue Type: Improvement
> Components: Compaction
>Reporter: Wei Deng
> Labels: compaction, lcs, performance
>
> I'm using the latest trunk (as of August 2016, which probably is going to be
> 3.10) to run some experiments on LeveledCompactionStrategy and noticed this
> inefficiency.
> The test data is generated using cassandra-stress default parameters
> (keyspace1.standard1), so as you can imagine, it consists of a ton of newly
> inserted partitions that will never merge in compactions, which is probably
> the worst kind of workload for LCS (however, I'll detail later why this
> scenario should not be ignored as a corner case; for now, let's just assume
> we still want to handle this scenario efficiently).
> After the compaction test is done, I scrubbed debug.log for patterns that
> match the "Compacted" summary so that I can see how long each individual
> compaction took and how many bytes they processed. The search pattern is like
> the following:
> {noformat}
> grep 'Compacted.*standard1' debug.log
> {noformat}
> Interestingly, I noticed a lot of the finished compactions are marked as
> having *only one* SSTable involved. With the workload mentioned above, the
> "single SSTable" compactions actually consist of the majority of all
> compactions (as shown below), so its efficiency can affect the overall
> compaction throughput quite a bit.
> {noformat}
> automaton@0ce59d338-1:~/cassandra-trunk/logs$ grep 'Compacted.*standard1'
> debug.log-test1 | wc -l
> 243
> automaton@0ce59d338-1:~/cassandra-trunk/logs$ grep 'Compacted.*standard1'
> debug.log-test1 | grep ") 1 sstable" | wc -l
> 218
> {noformat}
> By looking at the code, it appears that there's a way to directly edit the
> level of a particular SSTable like the following:
> {code}
> sstable.descriptor.getMetadataSerializer().mutateLevel(sstable.descriptor,
> targetLevel);
> sstable.reloadSSTableMetadata();
> {code}
> To be exact, I summed up the time spent for these single-SSTable compactions
> (the total data size is 60GB) and found that if each compaction only needs to
> spend 100ms for only the metadata change (instead of the 10+ second they're
> doing now), it can already achieve 22.75% saving on total compaction time.
> Compared to what we have now (reading the whole single-SSTable from old level
> and writing out the same single-SSTable at the new level), the only
> difference I could think of by using this approach is that the new SSTable
> will have the same file name (sequence number) as the old one's, which could
> break some assumptions on some other part of the code. However, not having to
> go through the full read/write IO, and not having to bear the overhead of
> cleaning up the old file, creating the new file, creating more churns in heap
> and file buffer, it seems the benefits outweigh the inconvenience. So I'd
> argue this JIRA belongs to LHF and should be made available in 3.0.x as well.
> As mentioned in the 2nd paragraph, I'm also going to address why this kind of
> all-new-partition workload should not be ignored as a corner case. Basically,
> for the main use case of LCS where you need to frequently merge partitions to
> optimize read and eliminate tombstones and expired data sooner, LCS can be
> perfectly happy and efficiently perform the partition merge and tombstone
> elimination for a long time. However, as soon as the node becomes a bit
> unhealthy for various reasons (could be a bad disk so it's missing a whole
> bunch of mutations and need repair, could be the user chooses to ingest way
> more data than it usually takes and exceeds its capability, or god-forbidden,
> some DBA chooses to run offline sstablelevelreset), you will have to handle
> this kind of "all-new-partition with a lot of SSTables in L0" scenario, and
> once all L0 SSTables finally gets up-leveled to L1, you will likely see a lot
> of such single-SSTable compactions, which is the situation this JIRA is
> intended to address.
> Actually, when I think more about this, to make this kind of single SSTable
> up-level more efficient will not only help the all-new-partition scenario,
> but also help in general any time when there is a big backlog of L0 SSTables
> due to too many flushes or excessive repair streaming with vnode. In those
> situations, by default STCS_in_L0 will be triggered, and you will end up
> getting a bunch of much bigger L0 SSTables after STCS is
cassandra git commit: use StringBuilder correctly
Repository: cassandra
Updated Branches:
refs/heads/trunk 7d593b760 -> 3c95d4731
use StringBuilder correctly
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3c95d473
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3c95d473
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3c95d473
Branch: refs/heads/trunk
Commit: 3c95d4731cfc1ad575f92e6c1944bf6f881e74d2
Parents: 7d593b7
Author: Dave Brosius
Authored: Sun Sep 4 12:19:16 2016 -0400
Committer: Dave Brosius
Committed: Sun Sep 4 12:19:16 2016 -0400
--
src/java/org/apache/cassandra/metrics/TableMetrics.java | 2 +-
src/java/org/apache/cassandra/tools/nodetool/Ring.java | 4 ++--
.../org/apache/cassandra/tools/nodetool/Status.java | 4 ++--
.../src/org/apache/cassandra/stress/StressProfile.java | 4 ++--
.../stress/settings/OptionAnyProbabilities.java | 10 +-
.../apache/cassandra/stress/settings/OptionMulti.java | 12 ++--
6 files changed, 18 insertions(+), 18 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c95d473/src/java/org/apache/cassandra/metrics/TableMetrics.java
--
diff --git a/src/java/org/apache/cassandra/metrics/TableMetrics.java
b/src/java/org/apache/cassandra/metrics/TableMetrics.java
index c57f240..0a726d4 100644
--- a/src/java/org/apache/cassandra/metrics/TableMetrics.java
+++ b/src/java/org/apache/cassandra/metrics/TableMetrics.java
@@ -952,7 +952,7 @@ public class TableMetrics
String groupName = TableMetrics.class.getPackage().getName();
StringBuilder mbeanName = new StringBuilder();
mbeanName.append(groupName).append(":");
-mbeanName.append("type=" + type);
+mbeanName.append("type=").append(type);
mbeanName.append(",name=").append(metricName);
return new CassandraMetricsRegistry.MetricName(groupName, type,
metricName, "all", mbeanName.toString());
}
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c95d473/src/java/org/apache/cassandra/tools/nodetool/Ring.java
--
diff --git a/src/java/org/apache/cassandra/tools/nodetool/Ring.java
b/src/java/org/apache/cassandra/tools/nodetool/Ring.java
index 55220a1..c6b9af1 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/Ring.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/Ring.java
@@ -72,7 +72,7 @@ public class Ring extends NodeToolCmd
String formatPlaceholder = "%%-%ds
%%-12s%%-7s%%-8s%%-16s%%-20s%%-44s%%n";
String format = format(formatPlaceholder, maxAddressLength);
-StringBuffer errors = new StringBuffer();
+StringBuilder errors = new StringBuilder();
boolean showEffectiveOwnership = true;
// Calculate per-token ownership of the ring
Map ownerships;
@@ -83,7 +83,7 @@ public class Ring extends NodeToolCmd
catch (IllegalStateException ex)
{
ownerships = probe.getOwnership();
-errors.append("Note: " + ex.getMessage() + "%n");
+errors.append("Note: ").append(ex.getMessage()).append("%n");
showEffectiveOwnership = false;
}
catch (IllegalArgumentException ex)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c95d473/src/java/org/apache/cassandra/tools/nodetool/Status.java
--
diff --git a/src/java/org/apache/cassandra/tools/nodetool/Status.java
b/src/java/org/apache/cassandra/tools/nodetool/Status.java
index a43b703..f7bb1e5 100644
--- a/src/java/org/apache/cassandra/tools/nodetool/Status.java
+++ b/src/java/org/apache/cassandra/tools/nodetool/Status.java
@@ -65,7 +65,7 @@ public class Status extends NodeToolCmd
hostIDMap = probe.getHostIdMap();
epSnitchInfo = probe.getEndpointSnitchInfoProxy();
-StringBuffer errors = new StringBuffer();
+StringBuilder errors = new StringBuilder();
Map ownerships = null;
boolean hasEffectiveOwns = false;
@@ -77,7 +77,7 @@ public class Status extends NodeToolCmd
catch (IllegalStateException e)
{
ownerships = probe.getOwnership();
-errors.append("Note: " + e.getMessage() + "%n");
+errors.append("Note: ").append(e.getMessage()).append("%n");
}
catch (IllegalArgumentException ex)
{
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3c95d473/tools/stress/src/org/apache/cassandra/stress/StressProfile.java
--
diff --git a/tools/stress/src/org/apache/cassandra/stress/StressProfile.java
b/tools/stres
[1/2] cassandra git commit: Fix NPE in SSTableLoader when specifying partial directory path
Repository: cassandra Updated Branches: refs/heads/trunk ca7256d76 -> 7d593b760 Fix NPE in SSTableLoader when specifying partial directory path patch by hkroger reviewed by dbrosius for CASSANDRA-12609 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/893fd21b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/893fd21b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/893fd21b Branch: refs/heads/trunk Commit: 893fd21b52254b1f7d68d87f6cf5f77f3010734b Parents: fa14804 Author: Hannu Kröger Authored: Sun Sep 4 10:36:37 2016 -0400 Committer: Dave Brosius Committed: Sun Sep 4 10:36:37 2016 -0400 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/tools/BulkLoader.java | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/893fd21b/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 21fc42c..798496a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -48,6 +48,7 @@ * Avoid digest mismatch with empty but static rows (CASSANDRA-12090) * Fix EOF exception when altering column type (CASSANDRA-11820) * Fix JsonTransformer output of partition with deletion info (CASSANDRA-12418) + * Fix NPE in SSTableLoader when specifying partial directory path (CASSANDRA-12609) Merged from 2.2: * Add local address entry in PropertyFileSnitch (CASSANDRA-11332) * cqlshlib tests: increase default execute timeout (CASSANDRA-12481) http://git-wip-us.apache.org/repos/asf/cassandra/blob/893fd21b/src/java/org/apache/cassandra/tools/BulkLoader.java -- diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java b/src/java/org/apache/cassandra/tools/BulkLoader.java index 2b2db15..9dba1b2 100644 --- a/src/java/org/apache/cassandra/tools/BulkLoader.java +++ b/src/java/org/apache/cassandra/tools/BulkLoader.java @@ -77,7 +77,7 @@ public class BulkLoader LoaderOptions options = LoaderOptions.parseArgs(args).validateArguments(); OutputHandler handler = new OutputHandler.SystemOutput(options.verbose, options.debug); SSTableLoader loader = new SSTableLoader( -options.directory, +options.directory.getAbsoluteFile(), new ExternalClient( options.hosts, options.nativePort,
[2/2] cassandra git commit: Merge branch 'cassandra-3.0' into trunk
Merge branch 'cassandra-3.0' into trunk
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/7d593b76
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/7d593b76
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/7d593b76
Branch: refs/heads/trunk
Commit: 7d593b760cbf0e617d88ec1337fea43d53be660a
Parents: ca7256d 893fd21
Author: Dave Brosius
Authored: Sun Sep 4 10:39:38 2016 -0400
Committer: Dave Brosius
Committed: Sun Sep 4 10:39:38 2016 -0400
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/tools/BulkLoader.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d593b76/CHANGES.txt
--
diff --cc CHANGES.txt
index 83060fb,798496a..c466dfe
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@@ -146,15 -47,14 +146,16 @@@ Merged from 3.0
those static columns in query results (CASSANDRA-12123)
* Avoid digest mismatch with empty but static rows (CASSANDRA-12090)
* Fix EOF exception when altering column type (CASSANDRA-11820)
+ * Fix potential race in schema during new table creation (CASSANDRA-12083)
+ * cqlsh: fix error handling in rare COPY FROM failure scenario
(CASSANDRA-12070)
+ * Disable autocompaction during drain (CASSANDRA-11878)
+ * Add a metrics timer to MemtablePool and use it to track time spent blocked
on memory in MemtableAllocator (CASSANDRA-11327)
+ * Fix upgrading schema with super columns with non-text subcomparators
(CASSANDRA-12023)
+ * Add TimeWindowCompactionStrategy (CASSANDRA-9666)
* Fix JsonTransformer output of partition with deletion info
(CASSANDRA-12418)
+ * Fix NPE in SSTableLoader when specifying partial directory path
(CASSANDRA-12609)
Merged from 2.2:
* Add local address entry in PropertyFileSnitch (CASSANDRA-11332)
- * cqlshlib tests: increase default execute timeout (CASSANDRA-12481)
- * Forward writes to replacement node when replace_address !=
broadcast_address (CASSANDRA-8523)
- * Enable repair -pr and -local together (fix regression of CASSANDRA-7450)
(CASSANDRA-12522)
- * Fail repair on non-existing table (CASSANDRA-12279)
* cqlsh copy: fix missing counter values (CASSANDRA-12476)
* Move migration tasks to non-periodic queue, assure flush executor shutdown
after non-periodic executor (CASSANDRA-12251)
* cqlsh copy: fixed possible race in initializing feeding thread
(CASSANDRA-11701)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/7d593b76/src/java/org/apache/cassandra/tools/BulkLoader.java
--
diff --cc src/java/org/apache/cassandra/tools/BulkLoader.java
index 7d10cdc,9dba1b2..0f1c555
--- a/src/java/org/apache/cassandra/tools/BulkLoader.java
+++ b/src/java/org/apache/cassandra/tools/BulkLoader.java
@@@ -42,18 -46,38 +42,18 @@@ import org.apache.cassandra.utils.Outpu
public class BulkLoader
{
-private static final String TOOL_NAME = "sstableloader";
-private static final String VERBOSE_OPTION = "verbose";
-private static final String HELP_OPTION = "help";
-private static final String NOPROGRESS_OPTION = "no-progress";
-private static final String IGNORE_NODES_OPTION = "ignore";
-private static final String INITIAL_HOST_ADDRESS_OPTION = "nodes";
-private static final String NATIVE_PORT_OPTION = "port";
-private static final String USER_OPTION = "username";
-private static final String PASSWD_OPTION = "password";
-private static final String AUTH_PROVIDER_OPTION = "auth-provider";
-private static final String THROTTLE_MBITS = "throttle";
-private static final String INTER_DC_THROTTLE_MBITS = "inter-dc-throttle";
-
-/* client encryption options */
-private static final String SSL_TRUSTSTORE = "truststore";
-private static final String SSL_TRUSTSTORE_PW = "truststore-password";
-private static final String SSL_KEYSTORE = "keystore";
-private static final String SSL_KEYSTORE_PW = "keystore-password";
-private static final String SSL_PROTOCOL = "ssl-protocol";
-private static final String SSL_ALGORITHM = "ssl-alg";
-private static final String SSL_STORE_TYPE = "store-type";
-private static final String SSL_CIPHER_SUITES = "ssl-ciphers";
-private static final String CONNECTIONS_PER_HOST = "connections-per-host";
-private static final String CONFIG_PATH = "conf-path";
-
-public static void main(String args[])
+public static void main(String args[]) throws BulkLoadException
{
-Config.setClientMode(true);
-LoaderOptions options =
LoaderOptions.parseArgs(args).validateArguments();
+LoaderOptions options =
L
[jira] [Resolved] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius resolved CASSANDRA-12609.
--
Resolution: Fixed
Reviewer: Dave Brosius
Fix Version/s: 3.10
committed to cassandra-3.0 as 893fd21b52254b1f7d68d87f6cf5f77f3010734b
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Minor
> Fix For: 3.10
>
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
cassandra git commit: Fix NPE in SSTableLoader when specifying partial directory path
Repository: cassandra Updated Branches: refs/heads/cassandra-3.0 fa1480454 -> 893fd21b5 Fix NPE in SSTableLoader when specifying partial directory path patch by hkroger reviewed by dbrosius for CASSANDRA-12609 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/893fd21b Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/893fd21b Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/893fd21b Branch: refs/heads/cassandra-3.0 Commit: 893fd21b52254b1f7d68d87f6cf5f77f3010734b Parents: fa14804 Author: Hannu Kröger Authored: Sun Sep 4 10:36:37 2016 -0400 Committer: Dave Brosius Committed: Sun Sep 4 10:36:37 2016 -0400 -- CHANGES.txt | 1 + src/java/org/apache/cassandra/tools/BulkLoader.java | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/893fd21b/CHANGES.txt -- diff --git a/CHANGES.txt b/CHANGES.txt index 21fc42c..798496a 100644 --- a/CHANGES.txt +++ b/CHANGES.txt @@ -48,6 +48,7 @@ * Avoid digest mismatch with empty but static rows (CASSANDRA-12090) * Fix EOF exception when altering column type (CASSANDRA-11820) * Fix JsonTransformer output of partition with deletion info (CASSANDRA-12418) + * Fix NPE in SSTableLoader when specifying partial directory path (CASSANDRA-12609) Merged from 2.2: * Add local address entry in PropertyFileSnitch (CASSANDRA-11332) * cqlshlib tests: increase default execute timeout (CASSANDRA-12481) http://git-wip-us.apache.org/repos/asf/cassandra/blob/893fd21b/src/java/org/apache/cassandra/tools/BulkLoader.java -- diff --git a/src/java/org/apache/cassandra/tools/BulkLoader.java b/src/java/org/apache/cassandra/tools/BulkLoader.java index 2b2db15..9dba1b2 100644 --- a/src/java/org/apache/cassandra/tools/BulkLoader.java +++ b/src/java/org/apache/cassandra/tools/BulkLoader.java @@ -77,7 +77,7 @@ public class BulkLoader LoaderOptions options = LoaderOptions.parseArgs(args).validateArguments(); OutputHandler handler = new OutputHandler.SystemOutput(options.verbose, options.debug); SSTableLoader loader = new SSTableLoader( -options.directory, +options.directory.getAbsoluteFile(), new ExternalClient( options.hosts, options.nativePort,
[jira] [Updated] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannu Kröger updated CASSANDRA-12609:
-
Summary: sstableloader NPE when partial directory path is given (was:
sstableloader NPE when relative directory path is given)
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12609) sstableloader NPE when relative directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannu Kröger updated CASSANDRA-12609:
-
Summary: sstableloader NPE when relative directory path is given (was:
sstableloader NPE when partial directory path is given)
> sstableloader NPE when relative directory path is given
> ---
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462832#comment-15462832
]
Hannu Kröger commented on CASSANDRA-12609:
--
This happens in multiple versions AFAIK. The fix is for the 3.9. It happens in
3.7 as well and probably many others.
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Brosius updated CASSANDRA-12609:
-
Assignee: Hannu Kröger
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Assignee: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462822#comment-15462822
]
Dave Brosius commented on CASSANDRA-12609:
--
LGTM, what version is this?
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
[
https://issues.apache.org/jira/browse/CASSANDRA-12609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannu Kröger updated CASSANDRA-12609:
-
Attachment: 12609-3.9.txt
Attached a very simple fix for the issue.
> sstableloader NPE when partial directory path is given
> --
>
> Key: CASSANDRA-12609
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
>Reporter: Hannu Kröger
>Priority: Minor
> Attachments: 12609-3.9.txt
>
>
> If a user is running sstableloader for example in the directory where the
> sstables are the parameter given is not the full /
> directory. That causes a NPE:
> {code}
> hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
> $ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
> Exception in thread "main" java.lang.NullPointerException
> at
> org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
> at
> org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-12609) sstableloader NPE when partial directory path is given
Hannu Kröger created CASSANDRA-12609:
Summary: sstableloader NPE when partial directory path is given
Key: CASSANDRA-12609
URL: https://issues.apache.org/jira/browse/CASSANDRA-12609
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Hannu Kröger
Priority: Minor
If a user is running sstableloader for example in the directory where the
sstables are the parameter given is not the full / directory.
That causes a NPE:
{code}
hkroger@home:~/data/temperatures/clients-f3ae39a0854411e5927a9f25d4de7071
$ ~/work/cassandra/bin/sstableloader -d 127.0.0.1 .
Exception in thread "main" java.lang.NullPointerException
at
org.apache.cassandra.io.sstable.SSTableLoader.(SSTableLoader.java:65)
at org.apache.cassandra.tools.BulkLoader.load(BulkLoader.java:65)
at org.apache.cassandra.tools.BulkLoader.main(BulkLoader.java:49)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
