[jira] [Assigned] (CASSANDRA-12968) Configurable password policy in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery reassigned CASSANDRA-12968: Assignee: (was: Amit Singh Chowdhery) > Configurable password policy in Cassandra > - > > Key: CASSANDRA-12968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Prakash Chauhan > Fix For: 3.x > > > In Apache Cassandra , there are no strict password policies for creating a > new user. > A new user can be created with a password as simple as "abc" which is not at > all recommended for production use. Moreover the same password can be used > again and again. > There should be a configurable password policy in Cassandra for creating new > users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-12968) Configurable password policy in Cassandra
[ https://issues.apache.org/jira/browse/CASSANDRA-12968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery reassigned CASSANDRA-12968: Assignee: Amit Singh Chowdhery > Configurable password policy in Cassandra > - > > Key: CASSANDRA-12968 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12968 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Prakash Chauhan >Assignee: Amit Singh Chowdhery > Fix For: 3.x > > > In Apache Cassandra , there are no strict password policies for creating a > new user. > A new user can be created with a password as simple as "abc" which is not at > all recommended for production use. Moreover the same password can be used > again and again. > There should be a configurable password policy in Cassandra for creating new > users. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11985) 2.0.x leaks file handles (Again)
[ https://issues.apache.org/jira/browse/CASSANDRA-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529895#comment-15529895 ] Amit Singh Chowdhery commented on CASSANDRA-11985: -- We tried finding fixes for tracking open files but didn't get much what we expected. So Sylvain Lebresne could you please provide few JIRA tickets related. It will of great help to us. Waiting for getting positive response from you . > 2.0.x leaks file handles (Again) > > > Key: CASSANDRA-11985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11985 > Project: Cassandra > Issue Type: Bug > Components: Compaction > Environment: Unix kernel-2.6.32-431.56.1.el6.x86_64, Cassandra 2.0.14 >Reporter: Amit Singh Chowdhery >Priority: Critical > Labels: Compaction > > We are running Cassandra 2.0.14 in production environment and disk usage is > very high. On investigating it further we found that there are around 4-5 > files(~ 150 GB) in stuck mode. > Command Fired : lsof /var/lib/cassandra | grep -i deleted > Output : > java12158 cassandra 308r REG 8,16 34396638044 12727268 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-16481-Data.db > (deleted) > java12158 cassandra 327r REG 8,16 101982374806 12715102 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-126861-Data.db > (deleted) > java12158 cassandra 339r REG 8,16 12966304784 12714010 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-213548-Data.db > (deleted) > java12158 cassandra 379r REG 8,16 15323318036 12714957 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-182936-Data.db > (deleted) > we are not able to see these files in any directory. This is somewhat similar > to CASSANDRA-6275 which is fixed but still issue is there on higher version. > Also in logs no error related to compaction is reported. > so could any one of you please provide any suggestion how to counter this. > Restarting Cassandra is one solution but this issue keeps on occurring so we > cannot restart production machine is not recommended so frequently. > Also we know that this version is not supported but there is high probability > that it can occur in higher version too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-11985) 2.0.x leaks file handles (Again)
[ https://issues.apache.org/jira/browse/CASSANDRA-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15489820#comment-15489820 ] Amit Singh Chowdhery commented on CASSANDRA-11985: -- Thanks a lot Sylvain Lebresne for the update, but it will be great if you can tell which version of Cassandra did your team has made changes so that we can give upgrade advice to customer who are running this system in Production. It will of great help to us. Hoping to see positive reply from you. > 2.0.x leaks file handles (Again) > > > Key: CASSANDRA-11985 > URL: https://issues.apache.org/jira/browse/CASSANDRA-11985 > Project: Cassandra > Issue Type: Bug > Components: Compaction > Environment: Unix kernel-2.6.32-431.56.1.el6.x86_64, Cassandra 2.0.14 >Reporter: Amit Singh Chowdhery >Priority: Critical > Labels: Compaction > > We are running Cassandra 2.0.14 in production environment and disk usage is > very high. On investigating it further we found that there are around 4-5 > files(~ 150 GB) in stuck mode. > Command Fired : lsof /var/lib/cassandra | grep -i deleted > Output : > java12158 cassandra 308r REG 8,16 34396638044 12727268 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-16481-Data.db > (deleted) > java12158 cassandra 327r REG 8,16 101982374806 12715102 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-126861-Data.db > (deleted) > java12158 cassandra 339r REG 8,16 12966304784 12714010 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-213548-Data.db > (deleted) > java12158 cassandra 379r REG 8,16 15323318036 12714957 > /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-182936-Data.db > (deleted) > we are not able to see these files in any directory. This is somewhat similar > to CASSANDRA-6275 which is fixed but still issue is there on higher version. > Also in logs no error related to compaction is reported. > so could any one of you please provide any suggestion how to counter this. > Restarting Cassandra is one solution but this issue keeps on occurring so we > cannot restart production machine is not recommended so frequently. > Also we know that this version is not supported but there is high probability > that it can occur in higher version too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-11985) 2.0.x leaks file handles (Again)
Amit Singh Chowdhery created CASSANDRA-11985: Summary: 2.0.x leaks file handles (Again) Key: CASSANDRA-11985 URL: https://issues.apache.org/jira/browse/CASSANDRA-11985 Project: Cassandra Issue Type: Bug Components: Compaction Environment: Unix kernel-2.6.32-431.56.1.el6.x86_64, Cassandra 2.0.14 Reporter: Amit Singh Chowdhery Priority: Critical We are running Cassandra 2.0.14 in production environment and disk usage is very high. On investigating it further we found that there are around 4-5 files(~ 150 GB) in stuck mode. Command Fired : lsof /var/lib/cassandra | grep -i deleted Output : java12158 cassandra 308r REG 8,16 34396638044 12727268 /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-16481-Data.db (deleted) java12158 cassandra 327r REG 8,16 101982374806 12715102 /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-126861-Data.db (deleted) java12158 cassandra 339r REG 8,16 12966304784 12714010 /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-213548-Data.db (deleted) java12158 cassandra 379r REG 8,16 15323318036 12714957 /var/lib/cassandra/data/mykeyspace/mycolumnfamily/mykeyspace-mycolumnfamily-jb-182936-Data.db (deleted) we are not able to see these files in any directory. This is somewhat similar to CASSANDRA-6275 which is fixed but still issue is there on higher version. Also in logs no error related to compaction is reported. so could any one of you please provide any suggestion how to counter this. Restarting Cassandra is one solution but this issue keeps on occurring so we cannot restart production machine is not recommended so frequently. Also we know that this version is not supported but there is high probability that it can occur in higher version too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194980#comment-15194980 ] Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 3/16/16 9:52 AM: --- Robert Stupp : As suggested by you , please find the patch with changes incorporated. CASSANDRA-10411.v3.patch contains the same. was (Author: achowdhe): Robert Stupp : As suggested by you , please find the patch with changes incorporated. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: CASSANDRA-10411.v3.patch, Cassandra-10411-trunk.diff, > cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15194980#comment-15194980 ] Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 3/16/16 9:52 AM: --- Robert Stupp : As suggested by you , please find the patch with changes incorporated. was (Author: achowdhe): As suggested , please find the patch with changes incorporated. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: CASSANDRA-10411.v3.patch, Cassandra-10411-trunk.diff, > cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-10411: - Attachment: CASSANDRA-10411.v3.patch As suggested , please find the patch with changes incorporated. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: CASSANDRA-10411.v3.patch, Cassandra-10411-trunk.diff, > cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15123144#comment-15123144 ] Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 1/29/16 7:37 AM: --- As communicated , please find the attached Patch for Trunk. In case of any issue , please let me know. was (Author: achowdhe): Patch for Trunk. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: Cassandra-10411-trunk.diff, cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-10411: - Attachment: Cassandra-10411-trunk.diff Patch for Trunk. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: Cassandra-10411-trunk.diff, cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075848#comment-15075848 ] Amit Singh Chowdhery commented on CASSANDRA-10411: -- Robert Stupp, I have taken Cassansdra formatter from https://github.com/tjake/cassandra-style-eclipse. I think the existing code file is not as per the recommended formatter. So once I applied the formatting, formatting changes popped up. Please verify it at your end too. Do you want me disable formatter and checkin file ? "it would also be ok to go one step further and to allow drops, alters and adds of columns in the same statement" I think we can have separate JIRA ticket for that. I would like to stick to current scope of JIRA which is about supporting multiple add/drops I will provide patch over trunk and will also check formatting in trunk. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Attachments: cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029486#comment-15029486
]
Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 12/30/15 11:56 AM:
-
Hi Team,
I think this will take CQL little closer to SQL and will allow little more
flexibility to user experience.
So I will pick this JIRA issue. I am thinking for the below changes(Just
blueprint) ::
Step 1: Change in Grammar src\java\org\apache\cassandra\cql3\Cql.g ,
altertablestatement will be changed for both ADD and DROP statements.
Step 2: After this corresponding java files will be changed to support above
grammar changes.
Requesting you all to provide Comments/suggestions for same.
Thanks
Amit Singh Chowdhery
was (Author: achowdhe):
Hi Team,
I think this will take CQL little closer to SQL and will allow little more
flexibility to user experience.
So I will pick this JIRA issue. I am thinking for the below changes(Just
blueprint) ::
Step 1: Change in Grammar src\java\org\apache\cassandra\cql3\Cql.g ,
altertablestatement will be changed for both ADD and DROP statements. it might
now look like :
For ADD -->
K_ADD ( { isStatic=true; } K_STATIC)? { type = AlterTableStatement.Type.ADD; }
c1=cident { mColumnName.add(c1); } v1=comparatorType {
mValidator.add(v1); }
( ',' cn=cident { mColumnName.add(cn); } vn=comparatorType
{ mValidator.add(vn); } )*
For DROP -->
K_DROP id=cident { mColumnName.add(id); } ( ',' cn=cident {
mColumnName.add(cn); } )* { type = AlterTableStatement.Type.DROP; }.
Step 2: After this corresponding java files will be changed to support above
grammar changes.
Requesting you all to provide Comments/suggestions for same.
Thanks
Amit Singh Chowdhery
> Add/drop multiple columns in one ALTER TABLE statement
> --
>
> Key: CASSANDRA-10411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10411
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Bryn Cooke
>Assignee: Amit Singh Chowdhery
>Priority: Minor
> Labels: patch
> Fix For: 2.0.17
>
> Attachments: cassandra-10411.diff
>
>
> Currently it is only possible to add one column at a time in an alter table
> statement. It would be great if we could add multiple columns at a time.
> The primary reason for this is that adding each column individually seems to
> take a significant amount of time (at least on my development machine), I
> know all the columns I want to add, but don't know them until after the
> initial table is created.
> As a secondary consideration it brings CQL slightly closer to SQL where most
> databases can handle adding multiple columns in one statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-10411: - Attachment: cassandra-10411.diff > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Fix For: 2.0.17 > > Attachments: cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15074966#comment-15074966 ] Amit Singh Chowdhery edited comment on CASSANDRA-10411 at 12/30/15 1:22 PM: In this patch , multiple columns addition and deletion has been entertained. New syntax for Addition will be : Alter table tablename add ( col1 datatype ,col2 datatype...coln datatype ); New Syntax for deletion will be : Alter table tablename drop (col1,col2,col3.col n); One can add single add and drop in same way which was earlier supported like : Alter table tablename drop col1; Alter table tablename add col1 datatype ; Currently attached patch is for branch 2.0.x , In case you find any issues in auto merging the change on 2.1,2.2 or 3 , please let me know , i will submit separate patches for that. was (Author: achowdhe): In this patch , multiple columns addition and deletion has been entertained. New syntax for Addition will be : Alter table tablename add ( col1 datatype ,col2 datatype...coln datatype ); New Syntax for deletion will be : Alter table tablename drop (col1,col2,col3.col n); One can add single add and drop in same way which was earlier supported like : Alter table tablename drop col1; Alter table tablename add col1 datatype ; Currently attached patch is for branch 2.0.x , In case to support for higher branches , please let me know i will upload that patch also. > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Fix For: 2.0.17 > > Attachments: cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-10411: - Attachment: cassandra-10411.diff > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Fix For: 2.0.17 > > Attachments: cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-10411: - Attachment: (was: cassandra-10411.diff) > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > Labels: patch > Fix For: 2.0.17 > > Attachments: cassandra-10411.diff > > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[
https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15029486#comment-15029486
]
Amit Singh Chowdhery commented on CASSANDRA-10411:
--
Hi Team,
I think this will take CQL little closer to SQL and will allow little more
flexibility to user experience.
So I will pick this JIRA issue. I am thinking for the below changes(Just
blueprint) ::
Step 1: Change in Grammar src\java\org\apache\cassandra\cql3\Cql.g ,
altertablestatement will be changed for both ADD and DROP statements. it might
now look like :
For ADD -->
K_ADD ( { isStatic=true; } K_STATIC)? { type = AlterTableStatement.Type.ADD; }
c1=cident { mColumnName.add(c1); } v1=comparatorType {
mValidator.add(v1); }
( ',' cn=cident { mColumnName.add(cn); } vn=comparatorType
{ mValidator.add(vn); } )*
For DROP -->
K_DROP id=cident { mColumnName.add(id); } ( ',' cn=cident {
mColumnName.add(cn); } )* { type = AlterTableStatement.Type.DROP; }.
Step 2: After this corresponding java files will be changed to support above
grammar changes.
Requesting you all to provide Comments/suggestions for same.
Thanks
Amit Singh Chowdhery
> Add/drop multiple columns in one ALTER TABLE statement
> --
>
> Key: CASSANDRA-10411
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10411
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Bryn Cooke
>Assignee: Amit Singh Chowdhery
>Priority: Minor
>
> Currently it is only possible to add one column at a time in an alter table
> statement. It would be great if we could add multiple columns at a time.
> The primary reason for this is that adding each column individually seems to
> take a significant amount of time (at least on my development machine), I
> know all the columns I want to add, but don't know them until after the
> initial table is created.
> As a secondary consideration it brings CQL slightly closer to SQL where most
> databases can handle adding multiple columns in one statement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10411) Add/drop multiple columns in one ALTER TABLE statement
[ https://issues.apache.org/jira/browse/CASSANDRA-10411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery reassigned CASSANDRA-10411: Assignee: Amit Singh Chowdhery > Add/drop multiple columns in one ALTER TABLE statement > -- > > Key: CASSANDRA-10411 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10411 > Project: Cassandra > Issue Type: New Feature >Reporter: Bryn Cooke >Assignee: Amit Singh Chowdhery >Priority: Minor > > Currently it is only possible to add one column at a time in an alter table > statement. It would be great if we could add multiple columns at a time. > The primary reason for this is that adding each column individually seems to > take a significant amount of time (at least on my development machine), I > know all the columns I want to add, but don't know them until after the > initial table is created. > As a secondary consideration it brings CQL slightly closer to SQL where most > databases can handle adding multiple columns in one statement. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8907) Raise GCInspector alerts to WARN
[ https://issues.apache.org/jira/browse/CASSANDRA-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14738560#comment-14738560 ] Amit Singh Chowdhery commented on CASSANDRA-8907: - Hi Joshua, I have looked into the changes and it seems fine. +1 from my side . > Raise GCInspector alerts to WARN > > > Key: CASSANDRA-8907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8907 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell >Assignee: Amit Singh Chowdhery > Labels: patch > Attachments: cassnadra-8907.patch > > > I'm fairly regularly running into folks wondering why their applications are > reporting down nodes. Yet, they report, when they grepped the logs they have > no WARN or ERRORs listed. > Nine times out of ten, when I look through the logs we see a ton of ParNew or > CMS gc pauses occurring similar to the following: > INFO [ScheduledTasks:1] 2013-03-07 18:44:46,795 GCInspector.java (line 122) > GC for ConcurrentMarkSweep: 1835 ms for 3 collections, 2606015656 used; max > is 10611589120 > INFO [ScheduledTasks:1] 2013-03-07 19:45:08,029 GCInspector.java (line 122) > GC for ParNew: 9866 ms for 8 collections, 2910124308 used; max is 6358564864 > To my mind these should be WARN's as they have the potential to be > significantly impacting the clusters performance as a whole. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8907) Raise GCInspector alerts to WARN
[ https://issues.apache.org/jira/browse/CASSANDRA-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-8907: Attachment: cassnadra-8907.patch Patch for 2.0.x > Raise GCInspector alerts to WARN > > > Key: CASSANDRA-8907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8907 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell > Attachments: cassnadra-8907.patch > > > I'm fairly regularly running into folks wondering why their applications are > reporting down nodes. Yet, they report, when they grepped the logs they have > no WARN or ERRORs listed. > Nine times out of ten, when I look through the logs we see a ton of ParNew or > CMS gc pauses occurring similar to the following: > INFO [ScheduledTasks:1] 2013-03-07 18:44:46,795 GCInspector.java (line 122) > GC for ConcurrentMarkSweep: 1835 ms for 3 collections, 2606015656 used; max > is 10611589120 > INFO [ScheduledTasks:1] 2013-03-07 19:45:08,029 GCInspector.java (line 122) > GC for ParNew: 9866 ms for 8 collections, 2910124308 used; max is 6358564864 > To my mind these should be WARN's as they have the potential to be > significantly impacting the clusters performance as a whole. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-8907) Raise GCInspector alerts to WARN
[ https://issues.apache.org/jira/browse/CASSANDRA-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-8907: Comment: was deleted (was: Please find attached the patch for 2.0.x .) > Raise GCInspector alerts to WARN > > > Key: CASSANDRA-8907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8907 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell > Attachments: cassnadra-8907.patch > > > I'm fairly regularly running into folks wondering why their applications are > reporting down nodes. Yet, they report, when they grepped the logs they have > no WARN or ERRORs listed. > Nine times out of ten, when I look through the logs we see a ton of ParNew or > CMS gc pauses occurring similar to the following: > INFO [ScheduledTasks:1] 2013-03-07 18:44:46,795 GCInspector.java (line 122) > GC for ConcurrentMarkSweep: 1835 ms for 3 collections, 2606015656 used; max > is 10611589120 > INFO [ScheduledTasks:1] 2013-03-07 19:45:08,029 GCInspector.java (line 122) > GC for ParNew: 9866 ms for 8 collections, 2910124308 used; max is 6358564864 > To my mind these should be WARN's as they have the potential to be > significantly impacting the clusters performance as a whole. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-8907) Raise GCInspector alerts to WARN
[ https://issues.apache.org/jira/browse/CASSANDRA-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery updated CASSANDRA-8907: Comment: was deleted (was: Patch for 2.0.x) > Raise GCInspector alerts to WARN > > > Key: CASSANDRA-8907 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8907 > Project: Cassandra > Issue Type: Improvement >Reporter: Adam Hattrell > Attachments: cassnadra-8907.patch > > > I'm fairly regularly running into folks wondering why their applications are > reporting down nodes. Yet, they report, when they grepped the logs they have > no WARN or ERRORs listed. > Nine times out of ten, when I look through the logs we see a ton of ParNew or > CMS gc pauses occurring similar to the following: > INFO [ScheduledTasks:1] 2013-03-07 18:44:46,795 GCInspector.java (line 122) > GC for ConcurrentMarkSweep: 1835 ms for 3 collections, 2606015656 used; max > is 10611589120 > INFO [ScheduledTasks:1] 2013-03-07 19:45:08,029 GCInspector.java (line 122) > GC for ParNew: 9866 ms for 8 collections, 2910124308 used; max is 6358564864 > To my mind these should be WARN's as they have the potential to be > significantly impacting the clusters performance as a whole. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-9955) In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes.
[ https://issues.apache.org/jira/browse/CASSANDRA-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Singh Chowdhery resolved CASSANDRA-9955. - Resolution: Fixed Reproduced In: 2.0.14, 2.0.3 (was: 2.0.3, 2.0.14) In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes. Key: CASSANDRA-9955 URL: https://issues.apache.org/jira/browse/CASSANDRA-9955 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.0.14, Hector Client (1.0.1), Red Hat Linux OS, Reporter: Amit Singh Chowdhery Issue : On 3 node cluster, inserts are happening normally but when 1 node was pulled down, After few minutes application stops and then failure start coming on both nodes. Hector keeps Exception Logs hector: ERROR m.p.c.c.ConcurrentHClientPool - Transport exception in re-opening client in release on ConcurrentCassandraClientPoolByHost. Cassandra Debug Logs : DEBUG [OptionalTasks:1] 2015-07-31 11:57:37,698 ColumnFamilyStore.java (line 300) retryPolicy for local is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:38,969 ColumnFamilyStore.java (line 300) retryPolicy for encryptionKey is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,492 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__batchIdIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,504 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.TX_STATEIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__serialNumberIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__subStateIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,828 ColumnFamilyStore.java (line 300) retryPolicy for vouchers is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,011 ColumnFamilyStore.java (line 300) retryPolicy for voucherHistory is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,021 ColumnFamilyStore.java (line 300) retryPolicy for vshash is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,180 ColumnFamilyStore.java (line 300) retryPolicy for vouchersByPurgeDate is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,395 ColumnFamilyStore.java (line 300) retryPolicy for serialNums is 0.99 DEBUG [Thrift:7] 2015-07-31 11:57:40,452 CassandraServer.java (line 311) get_slice DEBUG [Thrift:35] 2015-07-31 11:57:40,452 CassandraServer.java (line 943) batch_mutate DEBUG [MutationStage:56] 2015-07-31 11:57:40,453 StorageProxy.java (line 928) Adding hint for /192.168.5.65 DEBUG [Thrift:35] 2015-07-31 11:57:40,453 Tracing.java (line 159) request complete DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 62) resolving 2 responses DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 94) resolve: 0 ms. DEBUG [Thrift:7] 2015-07-31 11:57:40,454 StorageProxy.java (line 1275) Read: 1 ms. Steps to reproduce Step 1 : In 3 node cluster, on any 2 node start inserting records. Step 2 : Take down the node on which data insertion was not happening (init 0). Step 3: Failures can be seen on other 2 nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9955) In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes.
[ https://issues.apache.org/jira/browse/CASSANDRA-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14659901#comment-14659901 ] Amit Singh Chowdhery commented on CASSANDRA-9955: - Hi Jonathan..Thanks for the prompt response. Initially we debugged cassndra and was expecting this error from cassandra but later on ,we found issue is with 3PP that we used. Closing the ticket as no Cassnadra related exception found. Thanks a lot !! In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes. Key: CASSANDRA-9955 URL: https://issues.apache.org/jira/browse/CASSANDRA-9955 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.0.14, Hector Client (1.0.1), Red Hat Linux OS, Reporter: Amit Singh Chowdhery Issue : On 3 node cluster, inserts are happening normally but when 1 node was pulled down, After few minutes application stops and then failure start coming on both nodes. Hector keeps Exception Logs hector: ERROR m.p.c.c.ConcurrentHClientPool - Transport exception in re-opening client in release on ConcurrentCassandraClientPoolByHost. Cassandra Debug Logs : DEBUG [OptionalTasks:1] 2015-07-31 11:57:37,698 ColumnFamilyStore.java (line 300) retryPolicy for local is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:38,969 ColumnFamilyStore.java (line 300) retryPolicy for encryptionKey is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,492 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__batchIdIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,504 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.TX_STATEIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__serialNumberIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__subStateIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,828 ColumnFamilyStore.java (line 300) retryPolicy for vouchers is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,011 ColumnFamilyStore.java (line 300) retryPolicy for voucherHistory is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,021 ColumnFamilyStore.java (line 300) retryPolicy for vshash is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,180 ColumnFamilyStore.java (line 300) retryPolicy for vouchersByPurgeDate is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,395 ColumnFamilyStore.java (line 300) retryPolicy for serialNums is 0.99 DEBUG [Thrift:7] 2015-07-31 11:57:40,452 CassandraServer.java (line 311) get_slice DEBUG [Thrift:35] 2015-07-31 11:57:40,452 CassandraServer.java (line 943) batch_mutate DEBUG [MutationStage:56] 2015-07-31 11:57:40,453 StorageProxy.java (line 928) Adding hint for /192.168.5.65 DEBUG [Thrift:35] 2015-07-31 11:57:40,453 Tracing.java (line 159) request complete DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 62) resolving 2 responses DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 94) resolve: 0 ms. DEBUG [Thrift:7] 2015-07-31 11:57:40,454 StorageProxy.java (line 1275) Read: 1 ms. Steps to reproduce Step 1 : In 3 node cluster, on any 2 node start inserting records. Step 2 : Take down the node on which data insertion was not happening (init 0). Step 3: Failures can be seen on other 2 nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-9955) In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes.
Amit Singh Chowdhery created CASSANDRA-9955: --- Summary: In 3 node Cluster, when 1 node was forced down, data failures are observed in other 2 nodes. Key: CASSANDRA-9955 URL: https://issues.apache.org/jira/browse/CASSANDRA-9955 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.0.14, Hector Client (1.0.1), Red Hat Linux OS, Reporter: Amit Singh Chowdhery Issue : On 3 node cluster, inserts are happening normally but when 1 node was pulled down, After few minutes application stops and then failure start coming on both nodes. Hector keeps Exception Logs hector: ERROR m.p.c.c.ConcurrentHClientPool - Transport exception in re-opening client in release on ConcurrentCassandraClientPoolByHost. Cassandra Debug Logs : DEBUG [OptionalTasks:1] 2015-07-31 11:57:37,698 ColumnFamilyStore.java (line 300) retryPolicy for local is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:38,969 ColumnFamilyStore.java (line 300) retryPolicy for encryptionKey is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,492 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__batchIdIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,504 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.TX_STATEIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__serialNumberIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,824 ColumnFamilyStore.java (line 300) retryPolicy for vouchers.c_per__subStateIdx is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:39,828 ColumnFamilyStore.java (line 300) retryPolicy for vouchers is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,011 ColumnFamilyStore.java (line 300) retryPolicy for voucherHistory is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,021 ColumnFamilyStore.java (line 300) retryPolicy for vshash is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,180 ColumnFamilyStore.java (line 300) retryPolicy for vouchersByPurgeDate is 0.99 DEBUG [OptionalTasks:1] 2015-07-31 11:57:40,395 ColumnFamilyStore.java (line 300) retryPolicy for serialNums is 0.99 DEBUG [Thrift:7] 2015-07-31 11:57:40,452 CassandraServer.java (line 311) get_slice DEBUG [Thrift:35] 2015-07-31 11:57:40,452 CassandraServer.java (line 943) batch_mutate DEBUG [MutationStage:56] 2015-07-31 11:57:40,453 StorageProxy.java (line 928) Adding hint for /192.168.5.65 DEBUG [Thrift:35] 2015-07-31 11:57:40,453 Tracing.java (line 159) request complete DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 62) resolving 2 responses DEBUG [Thrift:7] 2015-07-31 11:57:40,453 RowDigestResolver.java (line 94) resolve: 0 ms. DEBUG [Thrift:7] 2015-07-31 11:57:40,454 StorageProxy.java (line 1275) Read: 1 ms. Steps to reproduce Step 1 : In 3 node cluster, on any 2 node start inserting records. Step 2 : Take down the node on which data insertion was not happening (init 0). Step 3: Failures can be seen on other 2 nodes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8907) Raise GCInspector alerts to WARN
[ https://issues.apache.org/jira/browse/CASSANDRA-8907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14585801#comment-14585801 ] Amit Singh Chowdhery commented on CASSANDRA-8907: - I am planning to pick this issue and provide a patch... Approach would be to add a property for GC warning threshold in yaml. Whenever the GC pause is equal to or greater than the configured time, a WARN message will be logged in Cassandra logs..else it will be logged at DEBUG level.. Please share your comments so that I can proceed with the fix.. Raise GCInspector alerts to WARN Key: CASSANDRA-8907 URL: https://issues.apache.org/jira/browse/CASSANDRA-8907 Project: Cassandra Issue Type: Improvement Reporter: Adam Hattrell I'm fairly regularly running into folks wondering why their applications are reporting down nodes. Yet, they report, when they grepped the logs they have no WARN or ERRORs listed. Nine times out of ten, when I look through the logs we see a ton of ParNew or CMS gc pauses occurring similar to the following: INFO [ScheduledTasks:1] 2013-03-07 18:44:46,795 GCInspector.java (line 122) GC for ConcurrentMarkSweep: 1835 ms for 3 collections, 2606015656 used; max is 10611589120 INFO [ScheduledTasks:1] 2013-03-07 19:45:08,029 GCInspector.java (line 122) GC for ParNew: 9866 ms for 8 collections, 2910124308 used; max is 6358564864 To my mind these should be WARN's as they have the potential to be significantly impacting the clusters performance as a whole. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8938) Full Row Scan does not count towards Reads
[ https://issues.apache.org/jira/browse/CASSANDRA-8938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14358038#comment-14358038 ] Amit Singh Chowdhery commented on CASSANDRA-8938: - Could somebody pls have a look in this issue...Thanks in advance. Full Row Scan does not count towards Reads -- Key: CASSANDRA-8938 URL: https://issues.apache.org/jira/browse/CASSANDRA-8938 Project: Cassandra Issue Type: Bug Components: API, Core, Tools Environment: Unix, Cassandra 2.0.3 Reporter: Amit Singh Chowdhery Priority: Minor Labels: none When a CQL SELECT statement is executed with WHERE clause, Read Count is incremented in cfstats of the column family. But, when a full row scan is done using SELECT statement without WHERE clause, Read Count is not incremented. Similarly, when using Size Tiered Compaction, if we do a full row scan using Hector RangeslicesQuery, Read Count is not incremented in cfstats, Cassandra still considers all sstables as cold and does not trigger compaction for them. If we fire MultigetSliceQuery, Read Count is incremented and sstables becomes hot, triggering compaction of these sstables. Expected Behavior: 1. Read Count must be incremented by number of rows read during a full row scan done using CQL SELECT statement or Hector RangeslicesQuery. 2. Size Tiered compaction must consider all sstables as Hot after a full row scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8938) Full Row Scan does not count towards Reads
Amit Singh Chowdhery created CASSANDRA-8938: --- Summary: Full Row Scan does not count towards Reads Key: CASSANDRA-8938 URL: https://issues.apache.org/jira/browse/CASSANDRA-8938 Project: Cassandra Issue Type: Bug Components: API, Core, Tools Environment: Unix, Cassandra 2.0.3 Reporter: Amit Singh Chowdhery Priority: Minor When a CQL SELECT statement is executed with WHERE clause, Read Count is incremented in cfstats of the column family. But, when a full row scan is done using SELECT statement without WHERE clause, Read Count is not incremented. Similarly, when using Size Tiered Compaction, if we do a full row scan using Hector RangeslicesQuery, Read Count is not incremented in cfstats, Cassandra still considers all sstables as cold and does not trigger compaction for them. If we fire MultigetSliceQuery, Read Count is incremented and sstables becomes hot, triggering compaction of these sstables. Expected Behavior: 1. Read Count must be incremented by number of rows read during a full row scan done using CQL SELECT statement or Hector RangeslicesQuery. 2. Size Tiered compaction must consider all sstables as Hot after a full row scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8479) Timeout Exception on Node Failure in Remote Data Center
Amit Singh Chowdhery created CASSANDRA-8479: --- Summary: Timeout Exception on Node Failure in Remote Data Center Key: CASSANDRA-8479 URL: https://issues.apache.org/jira/browse/CASSANDRA-8479 Project: Cassandra Issue Type: Bug Components: API, Core, Tools Environment: Unix, Cassandra 2.0.11 Reporter: Amit Singh Chowdhery Priority: Minor Fix For: 2.0.3 Issue Faced : We have a Geo-red setup with 2 Data centers having 3 nodes each. When we bring down a single Cassandra node down in DC2 by kill -9 Cassandra-pid, reads fail on DC1 with TimedOutException for a brief amount of time (15-20 sec~). Reference : Already a ticket has been opened/resolved and link is provided below : https://issues.apache.org/jira/browse/CASSANDRA-8352 Activity Done as per Resolution Provided : Upgraded to Cassandra 2.0.11 . We have two 3 node clusters in two different DCs and if one or more of the nodes go down in one Data Center , ~5-10% traffic failure is observed on the other. CL: LOCAL_QUORUM RF=3 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8352) Timeout Exception on Node Failure in Remote Data Center
[ https://issues.apache.org/jira/browse/CASSANDRA-8352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14239271#comment-14239271 ] Amit Singh Chowdhery commented on CASSANDRA-8352: - We have upgraded to Cassandra 2.0.11 and yet are facing the same trouble. Gist:- We have two 3 node clusters in two different DCs and if one or more of the nodes go down in one Data Center , ~5-10% traffic failure is observed on the other. CL: LOCAL_QUORUM RF=3 Timeout Exception on Node Failure in Remote Data Center --- Key: CASSANDRA-8352 URL: https://issues.apache.org/jira/browse/CASSANDRA-8352 Project: Cassandra Issue Type: Bug Environment: Unix, Cassandra 2.0.3 Reporter: Akhtar Hussain Labels: DataCenter, GEO-Red We have a Geo-red setup with 2 Data centers having 3 nodes each. When we bring down a single Cassandra node down in DC2 by kill -9 Cassandra-pid, reads fail on DC1 with TimedOutException for a brief amount of time (15-20 sec~). Questions: 1.We need to understand why reads fail on DC1 when a node in another DC i.e. DC2 fails? As we are using LOCAL_QUORUM for both reads/writes in DC1, request should return once 2 nodes in local DC have replied instead of timing out because of node in remote DC. 2.We want to make sure that no Cassandra requests fail in case of node failures. We used rapid read protection of ALWAYS/99percentile/10ms as mentioned in http://www.datastax.com/dev/blog/rapid-read-protection-in-cassandra-2-0-2. But nothing worked. How to ensure zero request failures in case a node fails? 3.What is the right way of handling HTimedOutException exceptions in Hector? 4.Please confirm are we using public private hostnames as expected? We are using Cassandra 2.0.3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
