[jira] [Commented] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16653166#comment-16653166
]
Jacques-Henri Berthemet commented on CASSANDRA-14631:
-
I confirm it's working, thank you!
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Assignee: Jeff Beck
>Priority: Major
> Labels: blog
> Attachments: 14631-site.txt, Screen Shot 2018-08-17 at 5.32.08
> PM.png, Screen Shot 2018-08-17 at 5.32.25 PM.png, feed404.png
>
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16625487#comment-16625487
]
Jacques-Henri Berthemet commented on CASSANDRA-14631:
-
I can see new feed icon, but if I click on it I get 404 error, see attached
screenshot:
!feed404.png!
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Assignee: Jeff Beck
>Priority: Major
> Labels: blog
> Attachments: 14631-site.txt, Screen Shot 2018-08-17 at 5.32.08
> PM.png, Screen Shot 2018-08-17 at 5.32.25 PM.png, feed404.png
>
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet updated CASSANDRA-14631:
Attachment: feed404.png
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Assignee: Jeff Beck
>Priority: Major
> Labels: blog
> Attachments: 14631-site.txt, Screen Shot 2018-08-17 at 5.32.08
> PM.png, Screen Shot 2018-08-17 at 5.32.25 PM.png, feed404.png
>
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Reopened] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet reopened CASSANDRA-14631:
-
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Assignee: Jeff Beck
>Priority: Major
> Labels: blog
> Attachments: 14631-site.txt, Screen Shot 2018-08-17 at 5.32.08
> PM.png, Screen Shot 2018-08-17 at 5.32.25 PM.png, feed404.png
>
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16585704#comment-16585704
]
Jacques-Henri Berthemet commented on CASSANDRA-14631:
-
I don't get the RSS icon neither with Chrome nor Firefox (Windows)
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Assignee: Jeff Beck
>Priority: Major
> Attachments: 14631-site.txt, Screen Shot 2018-08-17 at 5.32.08
> PM.png, Screen Shot 2018-08-17 at 5.32.25 PM.png
>
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575030#comment-16575030
]
Jacques-Henri Berthemet commented on CASSANDRA-14631:
-
Added Scott Andreas' response to the description.
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Priority: Major
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Updated] (CASSANDRA-14631) Add RSS support for Cassandra blog
[
https://issues.apache.org/jira/browse/CASSANDRA-14631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet updated CASSANDRA-14631:
Description:
It would be convenient to add RSS support to Cassandra blog:
[http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
And maybe also for other resources like new versions, but this ticket is about
blog.
{quote}From: Scott Andreas
Sent: Wednesday, August 08, 2018 6:53 PM
To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
Subject: Re: Apache Cassandra Blog is now live
Please feel free to file a ticket (label: Documentation and Website).
It looks like Jekyll, the static site generator used to build the website, has
a plugin that generates Atom feeds if someone would like to work on adding one:
[https://github.com/jekyll/jekyll-feed]
{quote}
was:
It would be convenient to add RSS support to Cassandra blog:
[http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
And maybe also for other resources like new versions, but this ticket is about
blog.
> Add RSS support for Cassandra blog
> --
>
> Key: CASSANDRA-14631
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14631
> Project: Cassandra
> Issue Type: Improvement
> Components: Documentation and Website
>Reporter: Jacques-Henri Berthemet
>Priority: Major
>
> It would be convenient to add RSS support to Cassandra blog:
> [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html]
> And maybe also for other resources like new versions, but this ticket is
> about blog.
>
> {quote}From: Scott Andreas
> Sent: Wednesday, August 08, 2018 6:53 PM
> To: [d...@cassandra.apache.org|mailto:d...@cassandra.apache.org]
> Subject: Re: Apache Cassandra Blog is now live
>
> Please feel free to file a ticket (label: Documentation and Website).
>
> It looks like Jekyll, the static site generator used to build the website,
> has a plugin that generates Atom feeds if someone would like to work on
> adding one: [https://github.com/jekyll/jekyll-feed]
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Created] (CASSANDRA-14631) Add RSS support for Cassandra blog
Jacques-Henri Berthemet created CASSANDRA-14631: --- Summary: Add RSS support for Cassandra blog Key: CASSANDRA-14631 URL: https://issues.apache.org/jira/browse/CASSANDRA-14631 Project: Cassandra Issue Type: Improvement Components: Documentation and Website Reporter: Jacques-Henri Berthemet It would be convenient to add RSS support to Cassandra blog: [http://cassandra.apache.org/blog/2018/08/07/faster_streaming_in_cassandra.html] And maybe also for other resources like new versions, but this ticket is about blog. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14304) DELETE after INSERT IF NOT EXISTS does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-14304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465912#comment-16465912
]
Jacques-Henri Berthemet commented on CASSANDRA-14304:
-
It looks like setting defaultTimestamp at statement level didn't work however
using
ServerSideTimestampGenerator.INSTANCE when building the session worked.
I think a warning should be written in docs around the LWT in CQL doc:
[http://cassandra.apache.org/doc/latest/cql/dml.html?#insert|http://cassandra.apache.org/doc/latest/cql/dml.html#insert]
Or it would be even better to have a dedicated chapter about LWT.
> DELETE after INSERT IF NOT EXISTS does not work
> ---
>
> Key: CASSANDRA-14304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14304
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Julien
>Assignee: Vinay Chella
>Priority: Major
> Attachments: debug.log, system.log
>
>
> DELETE a row immediately after INSERT IF NOT EXISTS does not work.
> Can be reproduced with this CQL script:
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> DELETE FROM ks.ta WHERE id = 'myId';
> SELECT * FROM ks.ta WHERE id='myId';
> {code}
> {code:java}
> [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> WARNING: pyreadline dependency missing. Install to enable tab completion.
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> cqlsh> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> [applied]
> ---
> True
> cqlsh> DELETE FROM ks.ta WHERE id = 'myId';
> cqlsh> SELECT * FROM ks.ta WHERE id='myId';
> id | col
> --+---
> myId | myCol
> {code}
> * Only happens if the client is on a different host (works as expected on
> the same host)
> * Works as expected without IF NOT EXISTS
> * A ~500 ms delay between INSERT and DELETE fixes the issue.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14304) DELETE after INSERT IF NOT EXISTS does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-14304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439207#comment-16439207
]
Jacques-Henri Berthemet commented on CASSANDRA-14304:
-
We're using DefaultRetryPolicy that will only "triggers a maximum of one retry,
and only in the case of a \{@code WriteType.BATCH_LOG} write"
Should we make our own retry policy to prevent retry of such batch? We use
batches to write large binary BLOBs chunked in smaller statements.
For us it's less of a problem to have a timeout than inconsistent data. However
using LWT everywhere seems overkill.
> DELETE after INSERT IF NOT EXISTS does not work
> ---
>
> Key: CASSANDRA-14304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14304
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Julien
>Assignee: Vinay Chella
>Priority: Major
> Attachments: debug.log, system.log
>
>
> DELETE a row immediately after INSERT IF NOT EXISTS does not work.
> Can be reproduced with this CQL script:
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> DELETE FROM ks.ta WHERE id = 'myId';
> SELECT * FROM ks.ta WHERE id='myId';
> {code}
> {code:java}
> [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> WARNING: pyreadline dependency missing. Install to enable tab completion.
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> cqlsh> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> [applied]
> ---
> True
> cqlsh> DELETE FROM ks.ta WHERE id = 'myId';
> cqlsh> SELECT * FROM ks.ta WHERE id='myId';
> id | col
> --+---
> myId | myCol
> {code}
> * Only happens if the client is on a different host (works as expected on
> the same host)
> * Works as expected without IF NOT EXISTS
> * A ~500 ms delay between INSERT and DELETE fixes the issue.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14304) DELETE after INSERT IF NOT EXISTS does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-14304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439133#comment-16439133
]
Jacques-Henri Berthemet commented on CASSANDRA-14304:
-
What would be the risk of forcing server generated timestamps for non-LWT
requests?
Would that be an effective workaround to the mixing of LWT and non-LWT requests?
> DELETE after INSERT IF NOT EXISTS does not work
> ---
>
> Key: CASSANDRA-14304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14304
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Julien
>Assignee: Vinay Chella
>Priority: Major
> Attachments: debug.log, system.log
>
>
> DELETE a row immediately after INSERT IF NOT EXISTS does not work.
> Can be reproduced with this CQL script:
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> DELETE FROM ks.ta WHERE id = 'myId';
> SELECT * FROM ks.ta WHERE id='myId';
> {code}
> {code:java}
> [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> WARNING: pyreadline dependency missing. Install to enable tab completion.
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> cqlsh> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> [applied]
> ---
> True
> cqlsh> DELETE FROM ks.ta WHERE id = 'myId';
> cqlsh> SELECT * FROM ks.ta WHERE id='myId';
> id | col
> --+---
> myId | myCol
> {code}
> * Only happens if the client is on a different host (works as expected on
> the same host)
> * Works as expected without IF NOT EXISTS
> * A ~500 ms delay between INSERT and DELETE fixes the issue.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-14304) DELETE after INSERT IF NOT EXISTS does not work
[
https://issues.apache.org/jira/browse/CASSANDRA-14304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16394970#comment-16394970
]
Jacques-Henri Berthemet commented on CASSANDRA-14304:
-
Hi [~vinaykumarcse],
I'm on the same team as [~Julien Moreau Genesys]. Make sure client and server
are on different physical hosts, docker/VMs on the same machine won't reproduce
the problem. Also it may be worth noting that this test was done on Windows.
I'm suspecting a clock problem, but having 500ms shift between client and
Cassandra should not be unexpected.
> DELETE after INSERT IF NOT EXISTS does not work
> ---
>
> Key: CASSANDRA-14304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14304
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Julien
>Assignee: Vinay Chella
>Priority: Major
> Attachments: debug.log, system.log
>
>
> DELETE a row immediately after INSERT IF NOT EXISTS does not work.
> Can be reproduced with this CQL script:
> {code:java}
> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> DELETE FROM ks.ta WHERE id = 'myId';
> SELECT * FROM ks.ta WHERE id='myId';
> {code}
> {code:java}
> [cqlsh 5.0.1 | Cassandra 3.11.2 | CQL spec 3.4.4 | Native protocol v4]
> Use HELP for help.
> WARNING: pyreadline dependency missing. Install to enable tab completion.
> cqlsh> CREATE KEYSPACE ks WITH REPLICATION = { 'class' : 'SimpleStrategy',
> 'replication_factor' : 1 };
> cqlsh> CREATE TABLE ks.ta ( id text PRIMARY KEY, col text );
> cqlsh> INSERT INTO ks.ta (id, col) VALUES ('myId', 'myCol') IF NOT EXISTS;
> [applied]
> ---
> True
> cqlsh> DELETE FROM ks.ta WHERE id = 'myId';
> cqlsh> SELECT * FROM ks.ta WHERE id='myId';
> id | col
> --+---
> myId | myCol
> {code}
> * Only happens if the client is on a different host (works as expected on
> the same host)
> * Works as expected without IF NOT EXISTS
> * A ~500 ms delay between INSERT and DELETE fixes the issue.
> Logs attached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12151) Audit logging for database activity
[ https://issues.apache.org/jira/browse/CASSANDRA-12151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16376850#comment-16376850 ] Jacques-Henri Berthemet commented on CASSANDRA-12151: - Proposed design looks good to me. I think using a file is better than a table as a rogue user may just truncate/drop/overwrite the table. I just have one question, do you think enabling/updating/disabling audit require a node restart? > Audit logging for database activity > --- > > Key: CASSANDRA-12151 > URL: https://issues.apache.org/jira/browse/CASSANDRA-12151 > Project: Cassandra > Issue Type: New Feature >Reporter: stefan setyadi >Assignee: Anuj Wadehra >Priority: Major > Fix For: 4.x > > Attachments: 12151.txt, > DesignProposal_AuditingFeature_ApacheCassandra_v1.docx > > > we would like a way to enable cassandra to log database activity being done > on our server. > It should show username, remote address, timestamp, action type, keyspace, > column family, and the query statement. > it should also be able to log connection attempt and changes to the > user/roles. > I was thinking of making a new keyspace and insert an entry for every > activity that occurs. > Then It would be possible to query for specific activity or a query targeting > a specific keyspace and column family. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-12743) Assertion error while running compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-12743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16155060#comment-16155060
]
Jacques-Henri Berthemet commented on CASSANDRA-12743:
-
[~krummas] I'm on the same team as [~jbleduigou], we just had a 60h perf
testing run without such issue, so it looks like it's not happening anymore.
> Assertion error while running compaction
> -
>
> Key: CASSANDRA-12743
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12743
> Project: Cassandra
> Issue Type: Bug
> Components: Compaction
> Environment: unix
>Reporter: Jean-Baptiste Le Duigou
>
> While running compaction I run into an error sometimes :
> {noformat}
> nodetool compact
> error: null
> -- StackTrace --
> java.lang.AssertionError
> at
> org.apache.cassandra.io.compress.CompressionMetadata$Chunk.(CompressionMetadata.java:463)
> at
> org.apache.cassandra.io.compress.CompressionMetadata.chunkFor(CompressionMetadata.java:228)
> at
> org.apache.cassandra.io.util.CompressedSegmentedFile.createMappedSegments(CompressedSegmentedFile.java:80)
> at
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.(CompressedPoolingSegmentedFile.java:38)
> at
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile$Builder.complete(CompressedPoolingSegmentedFile.java:101)
> at
> org.apache.cassandra.io.util.SegmentedFile$Builder.complete(SegmentedFile.java:198)
> at
> org.apache.cassandra.io.sstable.format.big.BigTableWriter.openEarly(BigTableWriter.java:315)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.maybeReopenEarly(SSTableRewriter.java:171)
> at
> org.apache.cassandra.io.sstable.SSTableRewriter.append(SSTableRewriter.java:116)
> at
> org.apache.cassandra.db.compaction.writers.DefaultCompactionWriter.append(DefaultCompactionWriter.java:64)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:184)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:74)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
> at
> org.apache.cassandra.db.compaction.CompactionManager$8.runMayThrow(CompactionManager.java:599)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Why is that happening?
> Is there anyway to provide more details (e.g. which SSTable cannot be
> compacted)?
> We are using Cassandra 2.2.7
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
[jira] [Commented] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
[
https://issues.apache.org/jira/browse/CASSANDRA-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947142#comment-15947142
]
Jacques-Henri Berthemet commented on CASSANDRA-13386:
-
done :)
> Can't start Cassandra with powershell script when connections are already
> established to other Cassandra nodes on the same host
> ---
>
> Key: CASSANDRA-13386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows with powershell
>Reporter: Jacques-Henri Berthemet
> Labels: easyfix, windows
> Attachments: cassandra.ps1.patch
>
>
> In our test env we run our client application on the same host as Cassandra
> nodes. When we restart the Cassandra node when the application is still
> running it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98
> with the below error:
> {code}
> VerifyPortsAreAvailable : Found a port already in use. Aborting startup
> At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
> + VerifyPortsAreAvailable
> + ~~~
> + CategoryInfo : NotSpecified: (:) [Write-Error],
> WriteErrorException
> + FullyQualifiedErrorId :
> Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
> VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
>ESTABLISHED
> {code}
> It looks like VerifyPortsAreAvailable is picking a remote 9042 port and
> refuses to start Cassandra.
> The VerifyPortsAreAvailable function should be fixed so that it only looks
> for LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
[
https://issues.apache.org/jira/browse/CASSANDRA-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet updated CASSANDRA-13386:
Attachment: cassandra.ps1.patch
> Can't start Cassandra with powershell script when connections are already
> established to other Cassandra nodes on the same host
> ---
>
> Key: CASSANDRA-13386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows with powershell
>Reporter: Jacques-Henri Berthemet
> Labels: easyfix, windows
> Attachments: cassandra.ps1.patch
>
>
> In our test env we run our client application on the same host as Cassandra
> nodes. When we restart the Cassandra node when the application is still
> running it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98
> with the below error:
> {code}
> VerifyPortsAreAvailable : Found a port already in use. Aborting startup
> At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
> + VerifyPortsAreAvailable
> + ~~~
> + CategoryInfo : NotSpecified: (:) [Write-Error],
> WriteErrorException
> + FullyQualifiedErrorId :
> Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
> VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
>ESTABLISHED
> {code}
> It looks like VerifyPortsAreAvailable is picking a remote 9042 port and
> refuses to start Cassandra.
> The VerifyPortsAreAvailable function should be fixed so that it only looks
> for LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
[
https://issues.apache.org/jira/browse/CASSANDRA-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet updated CASSANDRA-13386:
Attachment: cassandra.ps1.patch
> Can't start Cassandra with powershell script when connections are already
> established to other Cassandra nodes on the same host
> ---
>
> Key: CASSANDRA-13386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows with powershell
>Reporter: Jacques-Henri Berthemet
> Labels: easyfix, windows
>
> In our test env we run our client application on the same host as Cassandra
> nodes. When we restart the Cassandra node when the application is still
> running it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98
> with the below error:
> {code}
> VerifyPortsAreAvailable : Found a port already in use. Aborting startup
> At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
> + VerifyPortsAreAvailable
> + ~~~
> + CategoryInfo : NotSpecified: (:) [Write-Error],
> WriteErrorException
> + FullyQualifiedErrorId :
> Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
> VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
>ESTABLISHED
> {code}
> It looks like VerifyPortsAreAvailable is picking a remote 9042 port and
> refuses to start Cassandra.
> The VerifyPortsAreAvailable function should be fixed so that it only looks
> for LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
[
https://issues.apache.org/jira/browse/CASSANDRA-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacques-Henri Berthemet updated CASSANDRA-13386:
Attachment: (was: cassandra.ps1.patch)
> Can't start Cassandra with powershell script when connections are already
> established to other Cassandra nodes on the same host
> ---
>
> Key: CASSANDRA-13386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows with powershell
>Reporter: Jacques-Henri Berthemet
> Labels: easyfix, windows
>
> In our test env we run our client application on the same host as Cassandra
> nodes. When we restart the Cassandra node when the application is still
> running it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98
> with the below error:
> {code}
> VerifyPortsAreAvailable : Found a port already in use. Aborting startup
> At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
> + VerifyPortsAreAvailable
> + ~~~
> + CategoryInfo : NotSpecified: (:) [Write-Error],
> WriteErrorException
> + FullyQualifiedErrorId :
> Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
> VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
>ESTABLISHED
> {code}
> It looks like VerifyPortsAreAvailable is picking a remote 9042 port and
> refuses to start Cassandra.
> The VerifyPortsAreAvailable function should be fixed so that it only looks
> for LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
[
https://issues.apache.org/jira/browse/CASSANDRA-13386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15946873#comment-15946873
]
Jacques-Henri Berthemet commented on CASSANDRA-13386:
-
Thanks for the tip!
Maybe on line 321:
{code}
if ($line -match "TCP" -and $line -match $portRegex)
{code}
You should also match on "LISTENING"
> Can't start Cassandra with powershell script when connections are already
> established to other Cassandra nodes on the same host
> ---
>
> Key: CASSANDRA-13386
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Windows with powershell
>Reporter: Jacques-Henri Berthemet
> Labels: easyfix, windows
>
> In our test env we run our client application on the same host as Cassandra
> nodes. When we restart the Cassandra node when the application is still
> running it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98
> with the below error:
> {code}
> VerifyPortsAreAvailable : Found a port already in use. Aborting startup
> At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
> + VerifyPortsAreAvailable
> + ~~~
> + CategoryInfo : NotSpecified: (:) [Write-Error],
> WriteErrorException
> + FullyQualifiedErrorId :
> Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
> VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
>ESTABLISHED
> {code}
> It looks like VerifyPortsAreAvailable is picking a remote 9042 port and
> refuses to start Cassandra.
> The VerifyPortsAreAvailable function should be fixed so that it only looks
> for LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CASSANDRA-13386) Can't start Cassandra with powershell script when connections are already established to other Cassandra nodes on the same host
Jacques-Henri Berthemet created CASSANDRA-13386:
---
Summary: Can't start Cassandra with powershell script when
connections are already established to other Cassandra nodes on the same host
Key: CASSANDRA-13386
URL: https://issues.apache.org/jira/browse/CASSANDRA-13386
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Windows with powershell
Reporter: Jacques-Henri Berthemet
In our test env we run our client application on the same host as Cassandra
nodes. When we restart the Cassandra node when the application is still running
it fails in VerifyPortsAreAvailable function of bin\cassandra.ps1:98 with the
below error:
{code}
VerifyPortsAreAvailable : Found a port already in use. Aborting startup
At C:\apache-cassandra-2.2.7\bin\cassandra.ps1:98 char:9
+ VerifyPortsAreAvailable
+ ~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error],
WriteErrorException
+ FullyQualifiedErrorId :
Microsoft.PowerShell.Commands.WriteErrorException,VerifyPortsAreAvailable
VerifyPortsAreAvailable : TCPxxx.xx.xx.171:61936xxx.xx.xx.24:9042
ESTABLISHED
{code}
It looks like VerifyPortsAreAvailable is picking a remote 9042 port and refuses
to start Cassandra.
The VerifyPortsAreAvailable function should be fixed so that it only looks for
LISTENING ports.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CASSANDRA-11306) Add support for ALTER INDEX command
Jacques-Henri Berthemet created CASSANDRA-11306:
---
Summary: Add support for ALTER INDEX command
Key: CASSANDRA-11306
URL: https://issues.apache.org/jira/browse/CASSANDRA-11306
Project: Cassandra
Issue Type: Wish
Components: Core, CQL
Environment: Cassandra 2.2+
Reporter: Jacques-Henri Berthemet
Cassandra supports passing options to a (custom) secondary index at creation
time:
https://docs.datastax.com/en/cql/3.1/cql/cql_reference/create_index_r.html
{code}
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass' WITH
OPTIONS = {'storage': '/mnt/ssd/indexes/'};
{code}
However it is not possible to update the options for an existing index.
It would be great to have an ALTER INDEX command similar to the ALTER TABLE
command. Custom index implementation would receive the command and act
accordingly.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint
[
https://issues.apache.org/jira/browse/CASSANDRA-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15093552#comment-15093552
]
Jacques-Henri Berthemet commented on CASSANDRA-10477:
-
Will it be fixed in 2.2.x too?
> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041
> CassandraDaemon.java:223 - Exception in thread
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients
> get a lot of timeouts. We need to restart the affected Cassandra node to get
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the
> assert from being logged. At some point the read latency becomes bad again.
> Restarting the node where hinted handoff was disabled results in the read
> latency being better again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint
[
https://issues.apache.org/jira/browse/CASSANDRA-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15094166#comment-15094166
]
Jacques-Henri Berthemet commented on CASSANDRA-10477:
-
Great, thank you.
> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041
> CassandraDaemon.java:223 - Exception in thread
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients
> get a lot of timeouts. We need to restart the affected Cassandra node to get
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the
> assert from being logged. At some point the read latency becomes bad again.
> Restarting the node where hinted handoff was disabled results in the read
> latency being better again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10477) java.lang.AssertionError in StorageProxy.submitHint
[
https://issues.apache.org/jira/browse/CASSANDRA-10477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15091779#comment-15091779
]
Jacques-Henri Berthemet commented on CASSANDRA-10477:
-
I'm having the same problem on 2.2.3:
{code}
10:55:54.203 [ERROR] CassandraDaemon- Exception in thread
Thread[EXPIRING-MAP-REAPER:1,5,UCS-Threads] java.lang.AssertionError:
/
at
org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:978)
at
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:399)
at
org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:379)
at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
at
org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
What is the status on this issue? Can I expect this to be fixed in 2.2.x branch?
> java.lang.AssertionError in StorageProxy.submitHint
> ---
>
> Key: CASSANDRA-10477
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10477
> Project: Cassandra
> Issue Type: Bug
> Components: Local Write-Read Paths
> Environment: CentOS 6, Oracle JVM 1.8.45
>Reporter: Severin Leonhardt
>Assignee: Ariel Weisberg
> Fix For: 2.1.x, 2.2.x, 3.0.x, 3.x
>
>
> A few days after updating from 2.0.15 to 2.1.9 we have the following log
> entry on 2 of 5 machines:
> {noformat}
> ERROR [EXPIRING-MAP-REAPER:1] 2015-10-07 17:01:08,041
> CassandraDaemon.java:223 - Exception in thread
> Thread[EXPIRING-MAP-REAPER:1,5,main]
> java.lang.AssertionError: /192.168.11.88
> at
> org.apache.cassandra.service.StorageProxy.submitHint(StorageProxy.java:949)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:383)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.net.MessagingService$5.apply(MessagingService.java:363)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at org.apache.cassandra.utils.ExpiringMap$1.run(ExpiringMap.java:98)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-2.1.9.jar:2.1.9]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> [na:1.8.0_45]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> [na:1.8.0_45]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [na:1.8.0_45]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [na:1.8.0_45]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_45]
> {noformat}
> 192.168.11.88 is the broadcast address of the local machine.
> When this is logged the read request latency of the whole cluster becomes
> very bad, from 6 ms/op to more than 100 ms/op according to OpsCenter. Clients
> get a lot of timeouts. We need to restart the affected Cassandra node to get
> back normal read latencies. It seems write latency is not affected.
> Disabling hinted handoff using {{nodetool disablehandoff}} only prevents the
> assert from being logged. At some point the read latency becomes bad again.
> Restarting the node where hinted handoff was disabled results in the read
> latency being better again.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8453) Ability to override TTL on different data-centers, plus one-way replication
Jacques-Henri Berthemet created CASSANDRA-8453: -- Summary: Ability to override TTL on different data-centers, plus one-way replication Key: CASSANDRA-8453 URL: https://issues.apache.org/jira/browse/CASSANDRA-8453 Project: Cassandra Issue Type: Wish Components: Core Reporter: Jacques-Henri Berthemet Here is my scenario: I want to have one datacenter specialized for operations DCO and another for historical/audit DCH. Replication will be used between DCO and DCH. When TTL expires on DCO and data is deleted I'd like the data on DCH to be kept for other purposes. Ideally a different TTL could be set in DCH. I guess this also implies that replication should be done only in DCO = DCH direction so that data is not re-created. But that's secondary, DCH data is not meant to be modified. Is this kind of feature feasible for future versions of Cassandra? If not, would you have some pointers to modify Cassandra in order to achieve this functionality? Thank you. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8453) Ability to override TTL on different data-centers, plus one-way replication
[ https://issues.apache.org/jira/browse/CASSANDRA-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241103#comment-14241103 ] Jacques-Henri Berthemet commented on CASSANDRA-8453: What if I write a custom AbstractReplicationStrategy (extending NetworkTopologyStrategy) that would reset TTL info from the writes received from a non-local DC? Ability to override TTL on different data-centers, plus one-way replication --- Key: CASSANDRA-8453 URL: https://issues.apache.org/jira/browse/CASSANDRA-8453 Project: Cassandra Issue Type: Wish Components: Core Reporter: Jacques-Henri Berthemet Here is my scenario: I want to have one datacenter specialized for operations DCO and another for historical/audit DCH. Replication will be used between DCO and DCH. When TTL expires on DCO and data is deleted I'd like the data on DCH to be kept for other purposes. Ideally a different TTL could be set in DCH. I guess this also implies that replication should be done only in DCO = DCH direction so that data is not re-created. But that's secondary, DCH data is not meant to be modified. Is this kind of feature feasible for future versions of Cassandra? If not, would you have some pointers to modify Cassandra in order to achieve this functionality? Thank you. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8453) Ability to override TTL on different data-centers, plus one-way replication
[ https://issues.apache.org/jira/browse/CASSANDRA-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241118#comment-14241118 ] Jacques-Henri Berthemet commented on CASSANDRA-8453: Do you know which class receives/sends the replication messages from other DCs? Ability to override TTL on different data-centers, plus one-way replication --- Key: CASSANDRA-8453 URL: https://issues.apache.org/jira/browse/CASSANDRA-8453 Project: Cassandra Issue Type: Wish Components: Core Reporter: Jacques-Henri Berthemet Here is my scenario: I want to have one datacenter specialized for operations DCO and another for historical/audit DCH. Replication will be used between DCO and DCH. When TTL expires on DCO and data is deleted I'd like the data on DCH to be kept for other purposes. Ideally a different TTL could be set in DCH. I guess this also implies that replication should be done only in DCO = DCH direction so that data is not re-created. But that's secondary, DCH data is not meant to be modified. Is this kind of feature feasible for future versions of Cassandra? If not, would you have some pointers to modify Cassandra in order to achieve this functionality? Thank you. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8453) Ability to override TTL on different data-centers, plus one-way replication
[ https://issues.apache.org/jira/browse/CASSANDRA-8453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14241336#comment-14241336 ] Jacques-Henri Berthemet commented on CASSANDRA-8453: OK I understand. Thank you both for those detailed explanations. Regards, JH Ability to override TTL on different data-centers, plus one-way replication --- Key: CASSANDRA-8453 URL: https://issues.apache.org/jira/browse/CASSANDRA-8453 Project: Cassandra Issue Type: Wish Components: Core Reporter: Jacques-Henri Berthemet Here is my scenario: I want to have one datacenter specialized for operations DCO and another for historical/audit DCH. Replication will be used between DCO and DCH. When TTL expires on DCO and data is deleted I'd like the data on DCH to be kept for other purposes. Ideally a different TTL could be set in DCH. I guess this also implies that replication should be done only in DCO = DCH direction so that data is not re-created. But that's secondary, DCH data is not meant to be modified. Is this kind of feature feasible for future versions of Cassandra? If not, would you have some pointers to modify Cassandra in order to achieve this functionality? Thank you. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8317) ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
[
https://issues.apache.org/jira/browse/CASSANDRA-8317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14214630#comment-14214630
]
Jacques-Henri Berthemet commented on CASSANDRA-8317:
I see thanks for the info.
ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
--
Key: CASSANDRA-8317
URL: https://issues.apache.org/jira/browse/CASSANDRA-8317
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jacques-Henri Berthemet
Priority: Minor
Original Estimate: 1h
Remaining Estimate: 1h
ExtendedFilter countCQL3Rows should be exposed to isCQLCount(). The goal is
that a SecondaryIndexSearcher implementation knowns that it just needs to
count rows, not load them.
something like:
public boolean isCQLCount() {
return countCQL3Rows;
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8317) ExtendedFilter countCQL3Rows should be exposed to isCQLCount()
Jacques-Henri Berthemet created CASSANDRA-8317:
--
Summary: ExtendedFilter countCQL3Rows should be exposed to
isCQLCount()
Key: CASSANDRA-8317
URL: https://issues.apache.org/jira/browse/CASSANDRA-8317
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jacques-Henri Berthemet
Priority: Minor
ExtendedFilter countCQL3Rows should be exposed to isCQLCount(). The goal is
that a SecondaryIndexSearcher implementation knowns that it just needs to count
rows, not load them.
something like:
public boolean isCQLCount() {
return countCQL3Rows;
}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
