[ 
https://issues.apache.org/jira/browse/CASSANDRA-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15367702#comment-15367702
 ] 

Michael Frisch commented on CASSANDRA-11978:
--------------------------------------------

1) You are correct
2) I don't believe that changes made should affect the streaming scenario, but 
here are the non-defaults we're using:
partitioner: org.apache.cassandra.dht.RandomPartitioner
data_file_directories:
    - /data/cassandra/data
commitlog_directory: /data/cassandra/commitlog
key_cache_size_in_mb: 150
row_cache_size_in_mb: 30
saved_caches_directory: /data/cassandra/saved_caches
concurrent_reads: 128
concurrent_writes: 256
concurrent_counter_writes: 128
trickle_fsync: true
listen_address: 10.10.26.61
broadcast_address: 10.10.26.61
start_rpc: true
rpc_address: 10.10.26.61
rpc_server_type: hsha
rpc_min_threads: 32
rpc_max_threads: 1024
compaction_throughput_mb_per_sec: 0
stream_throughput_outbound_megabits_per_sec: 2000
streaming_socket_timeout_in_ms: 172800000
endpoint_snitch: GossipingPropertyFileSnitch
3) No, flush/drain both work fine. I've only see this error with streaming.

> StreamReader fails to write sstable if CF directory is symlink
> --------------------------------------------------------------
>
>                 Key: CASSANDRA-11978
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11978
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Streaming and Messaging
>            Reporter: Michael Frisch
>              Labels: lhf
>
> I'm using Cassandra v2.2.6.  If the CF is stored as a symlink in the keyspace 
> directory on disk then StreamReader.createWriter fails because 
> Descriptor.fromFilename is passed the actual path on disk instead of path 
> with the symlink.
> Example:
> /path/to/data/dir/Keyspace/CFName -> /path/to/data/dir/AnotherDisk/CFName
> Descriptor.fromFilename is passed "/path/to/data/dir/AnotherDisk/CFName" 
> instead of "/path/to/data/dir/Keyspace/CFName", then it concludes that the 
> keyspace name is "AnotherDisk" which is erroneous. I've temporarily worked 
> around this by using cfs.keyspace.getName() to get the keyspace name and 
> cfs.name to get the CF name as those are correct.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to