[jira] [Created] (CASSANDRA-11851) Table alias not supported
Prajakta Bhosale created CASSANDRA-11851: Summary: Table alias not supported Key: CASSANDRA-11851 URL: https://issues.apache.org/jira/browse/CASSANDRA-11851 Project: Cassandra Issue Type: Bug Components: CQL Environment: [cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0] Reporter: Prajakta Bhosale Priority: Minor Table alias not supported in CQL ... Getting below error message while accessing it ... cqlsh:test>select e.emp_id from emp e; Bad Request: line 1:25 no viable alternative at input 'e' Same query is working with w/o alias name as well as with column alias Below are version details : show version [cqlsh 4.1.1 | Cassandra 2.0.17 | CQL spec 3.1.1 | Thrift protocol 19.39.0] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8351) Running COPY FROM in cqlsh aborts with errors or segmentation fault
[
https://issues.apache.org/jira/browse/CASSANDRA-8351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354828#comment-14354828
]
Prajakta Bhosale commented on CASSANDRA-8351:
-
I'm getting the same issue on 2.1.2. errors message :
1- err: Segmentation fault (core dumped only once)
2- err: :1:line contains NULL byte :1:Aborting import at record
#7. Previously-inserted values still present. (Once in 10 attempts)
Not able to reproduce the issue on Cassandra 2.1.3, even after 15 attempts.
> Running COPY FROM in cqlsh aborts with errors or segmentation fault
> ---
>
> Key: CASSANDRA-8351
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8351
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joseph Chu
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.4
>
> Attachments: stress.cql, stress.csv
>
>
> Running Cassandra 2.1.2 binary tarball on a single instance.
> Put together a script to try to reproduce this using data generated by
> cassandra-stress.
> Reproduction steps: Download files and run cqlsh -f stress.cql
> This may need to run a couple of times before errors are encountered. I've
> seen this work best when running after a fresh install.
> Errors seen:
> 1.Segmentation fault (core dumped)
> 2.
> {code}
>stress.cql:24:line contains NULL byte
>stress.cql:24:Aborting import at record #0. Previously-inserted values
> still present.
>71 rows imported in 0.100 seconds.{code}
> 3.
> {code}*** glibc detected *** python: corrupted double-linked list:
> 0x01121ad0 ***
> === Backtrace: =
> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f80fe0cdb96]
> /lib/x86_64-linux-gnu/libc.so.6(+0x7fead)[0x7f80fe0ceead]
> python[0x42615d]
> python[0x501dc8]
> python[0x4ff715]
> python[0x425d02]
> python(PyEval_EvalCodeEx+0x1c4)[0x575db4]
> python[0x577be2]
> python(PyObject_Call+0x36)[0x4d91b6]
> python(PyEval_EvalFrameEx+0x2035)[0x54d8a5]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
> python(PyEval_EvalFrameEx+0xa02)[0x54c272]
> python(PyEval_EvalFrameEx+0xa02)[0x54c272]
> python(PyEval_EvalFrameEx+0xa02)[0x54c272]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python(PyEval_EvalFrameEx+0x7b8)[0x54c028]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python[0x577be2]
> python(PyObject_Call+0x36)[0x4d91b6]
> python(PyEval_EvalFrameEx+0x2035)[0x54d8a5]
> python(PyEval_EvalFrameEx+0xa02)[0x54c272]
> python(PyEval_EvalFrameEx+0xa02)[0x54c272]
> python(PyEval_EvalCodeEx+0x1a2)[0x575d92]
> python[0x577ab0]
> python(PyObject_Call+0x36)[0x4d91b6]
> python[0x4c91fa]
> python(PyObject_Call+0x36)[0x4d91b6]
> python(PyEval_CallObjectWithKeywords+0x36)[0x4d97c6]
> python[0x4f7f58]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f80ff369e9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f80fe1433fd]
> === Memory map:
> 0040-00672000 r-xp 08:01 1447344
> /usr/bin/python2.7
> 00871000-00872000 r--p 00271000 08:01 1447344
> /usr/bin/python2.7
> 00872000-008db000 rw-p 00272000 08:01 1447344
> /usr/bin/python2.7
> 008db000-008ed000 rw-p 00:00 0
> 0090e000-0126 rw-p 00:00 0
> [heap]
> 7f80ec00-7f80ec0aa000 rw-p 00:00 0
> 7f80ec0aa000-7f80f000 ---p 00:00 0
> 7f80f000-7f80f0021000 rw-p 00:00 0
> 7f80f0021000-7f80f400 ---p 00:00 0
> 7f80f400-7f80f4021000 rw-p 00:00 0
> 7f80f4021000-7f80f800 ---p 00:00 0
> 7f80fa713000-7f80fa714000 ---p 00:00 0
> 7f80fa714000-7f80faf14000 rw-p 00:00 0
> [stack:7493]
> 7f80faf14000-7f80faf15000 ---p 00:00 0
> 7f80faf15000-7f80fb715000 rw-p 00:00 0
> [stack:7492]
> 7f80fb715000-7f80fb716000 ---p 00:00 0
> 7f80fb716000-7f80fbf16000 rw-p 00:00 0
> [stack:7491]
> 7f80fbf16000-7f80fbf21000 r-xp 08:01 1456254
> /usr/lib/python2.7/lib-dynload/_json.so
> 7f80fbf21000-7f80fc12 ---p b000 08:01 1456254
> /usr/lib/python2.7/lib-dynload/_json.so
> 7f80fc12-7f80fc121000 r--p a000 08:01 1456254
> /usr/lib/python2.7/lib-dynload/_json.so
> 7f80fc121000-7f80fc122000 rw-p b000 08:01 1456254
> /usr/lib/python2.7/lib-dynload/_json.so
> 7f80fc122000-7f80fc133000 r-xp 08:01 1585974
[jira] [Commented] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd
[ https://issues.apache.org/jira/browse/CASSANDRA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14352953#comment-14352953 ] Prajakta Bhosale commented on CASSANDRA-8727: - We can update the Compaction using two ways though “Alter table & nodetool [en/dis]ableautocompcation” commands. Below are my observations regarding preferences : - Compaction Status set through Alter table command is Enabled : High preference is given to nodetool command - If we do nodetool enableautocompaction : compaction status will be enabled - If we do nodetool disableautocompaction : compaction status will be disabled - Compaction Status set through Alter table command is disabled : High preference is given to Alter table command. - nodetool command will not update the compaction status. > nodetool command to get the status of things that can be enable/disable'd > - > > Key: CASSANDRA-8727 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8727 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Brian Hess > > It is possible to say enableautocompaction or disableautocompaction via > nodetool. But it doesn't appear that there is a nodetool command to display > the current state of autocompaction - enabled or disabled. > It would be good to be able to get the status of these binary commands so > that you can determine the status, possibly make a change to > troubleshoot/experiment/etc, and return the status to the way it was when you > arrived. > This applies for autocompaction, backup, binary, gossip, handoff, and thrift. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8912) nodetool command to get the status of things that can be enable/disable'd for backup and handoff
[ https://issues.apache.org/jira/browse/CASSANDRA-8912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Prajakta Bhosale updated CASSANDRA-8912: Attachment: 8912.patch > nodetool command to get the status of things that can be enable/disable'd for > backup and handoff > > > Key: CASSANDRA-8912 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8912 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Prajakta Bhosale >Priority: Minor > Attachments: 8912.patch > > > request to create a nodetool quick display status for backup and handoff > statusbackup - Status of incremental backup > statushandoff - Status of storing future hints on the current node > similar to the following status commands: > statusbinary - Status of native transport (binary protocol) > statusgossip - Status of gossip > statusthrift - Status of thrift server > The output would just need to be simple as ON/OFF or similar TRUE/FALSE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8912) nodetool command to get the status of things that can be enable/disable'd for backup and handoff
Prajakta Bhosale created CASSANDRA-8912: --- Summary: nodetool command to get the status of things that can be enable/disable'd for backup and handoff Key: CASSANDRA-8912 URL: https://issues.apache.org/jira/browse/CASSANDRA-8912 Project: Cassandra Issue Type: Improvement Components: Tools Reporter: Prajakta Bhosale Priority: Minor request to create a nodetool quick display status for backup and handoff statusbackup - Status of incremental backup statushandoff - Status of storing future hints on the current node similar to the following status commands: statusbinary - Status of native transport (binary protocol) statusgossip - Status of gossip statusthrift - Status of thrift server The output would just need to be simple as ON/OFF or similar TRUE/FALSE. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd
[
https://issues.apache.org/jira/browse/CASSANDRA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14348156#comment-14348156
]
Prajakta Bhosale commented on CASSANDRA-8727:
-
While investigating the [en/dis]abledautocompactionfound flag, found below
behavior :
Setup :
Apache Cassandra 2.1.3
Created keyspace k1 which contains two columnfamily : enabledcomp &
disabledcomp having compaction enabled & disabled respectively. Disabled the
compaction using below command :
ALTER TABLE disabledcomp WITH COMPACTION = {'class':
'SizeTieredCompactionStrategy', 'enabled': 'false'};
Steps used :
- Added data into above 2 columnfamilies : Compaction is working as
expected.
- Ran below commands :
./nodetool enableautocompaction k1 disabledcomp
./nodetool disableautocompaction k1 enabledcomp
[**Even after enabling & disabling the auto compaction “describe table” command
not showing the correct status of “enable flag in compaction map”]
- Added data into 2 columnfamilies :
o Compaction is not running on “disabledcomp” columnfamily even though we
enabled the compaction using “nodetool enableautocompaction” command.
o Compaction is working as expected on “enabledcomp” columnfamily, when
we set it through “nodetool [en/dis]ableautocompaction” command.
Queries :
- Cant we modify the compaction of columnfamily using “nodetool
[en/dis]ableautocompaction” command, when it set through “ALTER TABLE” command.
- “Describe table” command only shows the compaction enabled status if it
is set through “ALTER TABLE” and not when it is set through “nodetool
[en/dis]ableautocompaction” command. Is it correct behavior ?
- If I am setting the compaction enable status using both the “Alter
table & nodetool” commands, which command is having higher preference?
> nodetool command to get the status of things that can be enable/disable'd
> -
>
> Key: CASSANDRA-8727
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8727
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Brian Hess
>
> It is possible to say enableautocompaction or disableautocompaction via
> nodetool. But it doesn't appear that there is a nodetool command to display
> the current state of autocompaction - enabled or disabled.
> It would be good to be able to get the status of these binary commands so
> that you can determine the status, possibly make a change to
> troubleshoot/experiment/etc, and return the status to the way it was when you
> arrived.
> This applies for autocompaction, backup, binary, gossip, handoff, and thrift.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8727) nodetool command to get the status of things that can be enable/disable'd
[ https://issues.apache.org/jira/browse/CASSANDRA-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343020#comment-14343020 ] Prajakta Bhosale commented on CASSANDRA-8727: - Out of 6 binary commands, below 3 are already implemented in "Apache Cassandra 2.1": - statusbinary - statusthrift - statusgossip For below commands code is ready from my side : - statusbackup - statushandoff And I am currently working on "statusautocompaction". > nodetool command to get the status of things that can be enable/disable'd > - > > Key: CASSANDRA-8727 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8727 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Brian Hess > > It is possible to say enableautocompaction or disableautocompaction via > nodetool. But it doesn't appear that there is a nodetool command to display > the current state of autocompaction - enabled or disabled. > It would be good to be able to get the status of these binary commands so > that you can determine the status, possibly make a change to > troubleshoot/experiment/etc, and return the status to the way it was when you > arrived. > This applies for autocompaction, backup, binary, gossip, handoff, and thrift. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8624) Cassandra Cluster's Status Inconsistency Strangely
[ https://issues.apache.org/jira/browse/CASSANDRA-8624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14336402#comment-14336402 ] Prajakta Bhosale commented on CASSANDRA-8624: - I tried to reproduce the same bug using apache cassandra-2.0.8 which dse-4.5.1 uses but couldn't reproduce. Tried the stress test with @6lakh records, still things are working as expected. The node is shown as down if there is network issue. I also tried with apache cassandra-2.1.2 and the same happened with it too. > Cassandra Cluster's Status Inconsistency Strangely > -- > > Key: CASSANDRA-8624 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8624 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Cassandra 1.2.11 >Reporter: ZhongYu >Priority: Minor > Attachments: QQ截图20150115125254.png > > > We found a strange phenomenon about Cassandra Cluster's status that all the > nodes in the cluster found other node's status inconsistency. Especially, the > inconsistency has an interesting patten. See the following example: > There are 5 nodes (pc17, pc19, pc21, pc23, pc25) in the cluster. Their seeds > configuration are all "pc17, pc19, pc21, pc23, pc25". In a moment, > pc17 found others UP; > pc19 found pc17 DN, others UP; > pc21 found pc17, pc19 DN, others UP; > pc23 found pc17, pc19, pc21 DN, others UP; > pc25 found pc17, pc19, pc21, pc23 DN, only self UP; > See attachments as screen's snapshot. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8102) cassandra-cli and cqlsh report two different values for a setting, partially update it and partially report it
[
https://issues.apache.org/jira/browse/CASSANDRA-8102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328542#comment-14328542
]
Prajakta Bhosale commented on CASSANDRA-8102:
-
I am looking into this bug & below are my observations :
- While looking into the cassandra-cli code found below comments in
executeUpdateColumnFamily():
// request correct cfDef from the server (we let that call include CQL3 cf even
though
// they can't be modified by thrift because the error message that will be
thrown by
// system_update_column_family will be more useful)
I tried to update the gc_grace_seconds and index” attributes of columnfamily
through cli & they are updated properly. They were also reflected through cqlsh.
We are getting an issue for “min_compaction_threshold”.
So are the above comment applicable only for some of the attributes of
columnfamily ?
> cassandra-cli and cqlsh report two different values for a setting, partially
> update it and partially report it
> --
>
> Key: CASSANDRA-8102
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8102
> Project: Cassandra
> Issue Type: Bug
> Environment: 2.0.9
>Reporter: Peter Haggerty
>Priority: Minor
> Labels: cli, cqlsh
>
> cassandra-cli updates and prints out a min_compaction_threshold that is not
> shown by cqlsh (it shows a different min_threshold attribute)
> cqlsh updates "both" values but only shows one of them
> {code}
> cassandra-cli:
> UPDATE COLUMN FAMILY foo WITH min_compaction_threshold = 8;
> $ echo "describe foo;" | cassandra-cli -h `hostname` -k bar
> Compaction min/max thresholds: 8/32
> $ echo "describe table foo;" | cqlsh -k bar `hostname`
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> {code}
> {code}
> cqlsh:
> ALTER TABLE foo WITH compaction = {'class' : 'SizeTieredCompactionStrategy',
> 'min_threshold' : 16};
> cassandra-cli:
> Compaction min/max thresholds: 16/32
> Compaction Strategy Options:
> min_threshold: 16
> cqlsh:
> compaction={'min_threshold': '16', 'class': 'SizeTieredCompactionStrategy'}
> AND
> {code}
> {code}
> cassandra-cli:
> UPDATE COLUMN FAMILY foo WITH min_compaction_threshold = 8;
> cassandra-cli:
> Compaction min/max thresholds: 8/32
> Compaction Strategy Options:
> min_threshold: 16
> cqlsh:
> compaction={'min_threshold': '16', 'class': 'SizeTieredCompactionStrategy'}
> AND
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8610) Allow IF EXISTS for UPDATE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Prajakta Bhosale updated CASSANDRA-8610:
Attachment: 8610.patch
Check for if Exists
> Allow IF EXISTS for UPDATE statements
> -
>
> Key: CASSANDRA-8610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8610
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: Cassandra 2.1.2
>Reporter: DOAN DuyHai
>Priority: Minor
> Attachments: 8610.patch
>
>
> While creating a hands-on exercice for Cassandra, I was facing a quite
> annoying limitation.
> Let's take this table:
> {code:sql}
> CREATE TABLE killrchat.chat_rooms(
> room_name text,
> creation_date timestamp,
> banner text,
> creator text,
> participants set,
> PRIMARY KEY(room_name));
> {code}
> Upon a new participant joining the room, to be concurrency-proof (avoiding
> mutating the participants set if the room is deleted concurrently), I would
> like to issue this query:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF EXISTS;
> {code}
> Unfortunately the clause IF EXISTS is not allowed for UPDATE statements.
> Similarly I tried
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF room_name='games';
> {code}
> It doesn't work either, it is not allowed to use one column of the primary
> key as condition column for LWT (why ? mystery).
> So far, the only work-around I found is:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF name='games';
> {code}
> I added an extra column called *name* which is just the duplicate of the
> partition key *room_name*. It does work but is not very elegant.
> I believe there are legit use cases for UPDATE ... IF EXISTS;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8610) Allow IF EXISTS for UPDATE statements
[
https://issues.apache.org/jira/browse/CASSANDRA-8610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296682#comment-14296682
]
Prajakta Bhosale commented on CASSANDRA-8610:
-
I am taking up this JIRA. I already have the patch for the same,will upload
after testing.
> Allow IF EXISTS for UPDATE statements
> -
>
> Key: CASSANDRA-8610
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8610
> Project: Cassandra
> Issue Type: Improvement
> Components: API
> Environment: Cassandra 2.1.2
>Reporter: DOAN DuyHai
>Priority: Minor
>
> While creating a hands-on exercice for Cassandra, I was facing a quite
> annoying limitation.
> Let's take this table:
> {code:sql}
> CREATE TABLE killrchat.chat_rooms(
> room_name text,
> creation_date timestamp,
> banner text,
> creator text,
> participants set,
> PRIMARY KEY(room_name));
> {code}
> Upon a new participant joining the room, to be concurrency-proof (avoiding
> mutating the participants set if the room is deleted concurrently), I would
> like to issue this query:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF EXISTS;
> {code}
> Unfortunately the clause IF EXISTS is not allowed for UPDATE statements.
> Similarly I tried
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF room_name='games';
> {code}
> It doesn't work either, it is not allowed to use one column of the primary
> key as condition column for LWT (why ? mystery).
> So far, the only work-around I found is:
> {code:sql}
> UPDATE chat_rooms SET participants = participants + {'johnny'} WHERE
> room_name = 'games' IF name='games';
> {code}
> I added an extra column called *name* which is just the duplicate of the
> partition key *room_name*. It does work but is not very elegant.
> I believe there are legit use cases for UPDATE ... IF EXISTS;
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6538) Provide a read-time CQL function to display the data size of columns and rows
[ https://issues.apache.org/jira/browse/CASSANDRA-6538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282474#comment-14282474 ] Prajakta Bhosale commented on CASSANDRA-6538: - Yes even I agree, It would be useful in my scenario : I am trying to copy the columnfamily data to .csv files using "COPY TO" command: for records > "7 lakh" cassandra node going down without copying the data into .csv file. So we decided to copy only required columns instead of complete table, which allow me to copy records > 7lakh without node failure. If we will come to know the size of columns it will help us to decide number of columns to copy in .csv using "COPY TO" command. > Provide a read-time CQL function to display the data size of columns and rows > - > > Key: CASSANDRA-6538 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6538 > Project: Cassandra > Issue Type: Improvement >Reporter: Johnny Miller >Priority: Minor > Labels: cql > > It would be extremely useful to be able to work out the size of rows and > columns via CQL. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8644) Cassandra node going down while running "COPY TO" command on around 7lakh records.....
Prajakta Bhosale created CASSANDRA-8644: --- Summary: Cassandra node going down while running "COPY TO" command on around 7lakh records. Key: CASSANDRA-8644 URL: https://issues.apache.org/jira/browse/CASSANDRA-8644 Project: Cassandra Issue Type: Bug Reporter: Prajakta Bhosale Attachments: cassandra.yaml Cassandra node going down, While running the "Copy TO" command on one of my colum-family which contains around 7 lakh records. We have 4 node cluster. Please find attached cassandra config file. $ cassandra -v 2.0.6 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
