[jira] [Updated] (CASSANDRA-10540) RangeAwareCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lerh Chuan Low updated CASSANDRA-10540:
---
Description:
Broken out from CASSANDRA-6696, we should split sstables based on ranges during
compaction.
Requirements;
* dont create tiny sstables - keep them bunched together until a single vnode
is big enough (configurable how big that is)
* make it possible to run existing compaction strategies on the per-range
sstables
We should probably add a global compaction strategy parameter that states
whether this should be enabled or not.
was:
{color:red}colored text{color}Broken out from CASSANDRA-6696, we should split
sstables based on ranges during compaction.
Requirements;
* dont create tiny sstables - keep them bunched together until a single vnode
is big enough (configurable how big that is)
* make it possible to run existing compaction strategies on the per-range
sstables
We should probably add a global compaction strategy parameter that states
whether this should be enabled or not.
> RangeAwareCompaction
>
>
> Key: CASSANDRA-10540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10540
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Labels: compaction, lcs, vnodes
> Fix For: 4.x
>
>
> Broken out from CASSANDRA-6696, we should split sstables based on ranges
> during compaction.
> Requirements;
> * dont create tiny sstables - keep them bunched together until a single vnode
> is big enough (configurable how big that is)
> * make it possible to run existing compaction strategies on the per-range
> sstables
> We should probably add a global compaction strategy parameter that states
> whether this should be enabled or not.
--
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-14365) Commit log replay failure for static columns with collections in clustering keys
Vincent White created CASSANDRA-14365:
-
Summary: Commit log replay failure for static columns with
collections in clustering keys
Key: CASSANDRA-14365
URL: https://issues.apache.org/jira/browse/CASSANDRA-14365
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Vincent White
In the old storage engine, static cells with a collection as part of the
clustering key fail to validate because a 0 byte collection (like in the cell
name of a static cell) isn't valid.
To reproduce:
1.
{code:java}
CREATE TABLE test.x (
id int,
id2 frozen>,
st int static,
PRIMARY KEY (id, id2)
);
INSERT INTO test.x (id, st) VALUES (1, 2);
{code}
2.
Kill the cassandra process
3.
Restart cassandra to replay the commitlog
Outcome:
{noformat}
ERROR [main] 2018-04-05 04:58:23,741 JVMStabilityInspector.java:99 - Exiting
due to error while processing commit log during initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
Unexpected error deserializing mutation; saved to
/tmp/mutation3825739904516830950dat. This may be caused by replaying a
mutation against a table with the same name but incompatible schema. Exception
follows: org.apache.cassandra.serializers.MarshalException: Not enough bytes to
read a set
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:638)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.replayMutation(CommitLogReplayer.java:565)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.replaySyncSection(CommitLogReplayer.java:517)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:397)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:143)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:181)
[main/:na]
at
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:161)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:284)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:533)
[main/:na]
at
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:642)
[main/:na]
{noformat}
I haven't investigated if there are other more subtle issues caused by these
cells failing to validate other places in the code, but I believe the fix for
this is to check for 0 byte length collections and accept them as valid as we
do with other types.
I haven't had a chance for any extensive testing but this naive patch seems to
have the desired affect. [2.2 PoC
Patch|https://github.com/vincewhite/cassandra/commits/zero_length_collection]
--
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-13653) Create meaningful toString() methods
[
https://issues.apache.org/jira/browse/CASSANDRA-13653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426478#comment-16426478
]
Jogesh Anand commented on CASSANDRA-13653:
--
Hi [~djoshi3] - Thank you. Removed them and squashed the [commit
|https://github.com/djanand/cassandra/commit/f9d6982c9d54d07938aaec84d54c4e4b536b0ed9]
> Create meaningful toString() methods
>
>
> Key: CASSANDRA-13653
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13653
> Project: Cassandra
> Issue Type: Bug
>Reporter: Jeff Jirsa
>Assignee: Jogesh Anand
>Priority: Trivial
> Labels: lhf, low-hanging-fruit
>
> True low-hanging fruit, good for a first-time contributor:
> There are a lot of classes without meaningful {{toString()}} implementations.
> Some of these would be very nice to have for investigating bug reports.
> Some good places to start:
> - CQL3 statements (UpdateStatement, DeleteStatement, etc), QueryOptions, and
> Restrictions
> Some packages not to worry about:
> - Deep internals that don't already have them
> (org.apache.cassandra.db.rows/partitions/etc)
--
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-10540) RangeAwareCompaction
[
https://issues.apache.org/jira/browse/CASSANDRA-10540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lerh Chuan Low updated CASSANDRA-10540:
---
Description:
{color:red}colored text{color}Broken out from CASSANDRA-6696, we should split
sstables based on ranges during compaction.
Requirements;
* dont create tiny sstables - keep them bunched together until a single vnode
is big enough (configurable how big that is)
* make it possible to run existing compaction strategies on the per-range
sstables
We should probably add a global compaction strategy parameter that states
whether this should be enabled or not.
was:
Broken out from CASSANDRA-6696, we should split sstables based on ranges during
compaction.
Requirements;
* dont create tiny sstables - keep them bunched together until a single vnode
is big enough (configurable how big that is)
* make it possible to run existing compaction strategies on the per-range
sstables
We should probably add a global compaction strategy parameter that states
whether this should be enabled or not.
> RangeAwareCompaction
>
>
> Key: CASSANDRA-10540
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10540
> Project: Cassandra
> Issue Type: New Feature
>Reporter: Marcus Eriksson
>Assignee: Marcus Eriksson
>Priority: Major
> Labels: compaction, lcs, vnodes
> Fix For: 4.x
>
>
> {color:red}colored text{color}Broken out from CASSANDRA-6696, we should split
> sstables based on ranges during compaction.
> Requirements;
> * dont create tiny sstables - keep them bunched together until a single vnode
> is big enough (configurable how big that is)
> * make it possible to run existing compaction strategies on the per-range
> sstables
> We should probably add a global compaction strategy parameter that states
> whether this should be enabled or not.
--
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] [Comment Edited] (CASSANDRA-14362) Node unable to join cluster in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-14362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426241#comment-16426241
]
Jason Brown edited comment on CASSANDRA-14362 at 4/5/18 1:58 AM:
-
So it looks like when working on CASSANDRA-8457/CASSANDRA-12229, I introduced a
regression of CASSANDRA-12673. The short of it is we no longer bind the local
side of a outbound connection as of CASSANDRA-12673, yet I mistakenly brought
that back (see
[{{NettyFactory#createOutboundBootstrap()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/NettyFactory.java#L337]).
I believe the most correct fix is just not setting the local address to bind to
for outbound connections, as that's bascially what CASSANDRA-12673 does.
Removing the local bind should resolve [~Lerh Low]'s error as well as eliminate
the regression against CASSANDRA-12673. However, we should also incorporate
[~Lerh Low]'s fix as well, to clarify the intent of which address we want to
'reference' (but not actually use) on the local side.
||14362||
|[branch|https://github.com/jasobrown/cassandra/tree/14362]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14362]|
tests are running now.
[~aweisberg] do you mind reviewing?
UPDATE: dtests seem to be pretty unhappy. I'll investigate what's wrong and
ping this ticket with updates.
was (Author: jasobrown):
So it looks like when working on CASSANDRA-8457/CASSANDRA-12229, I introduced a
regression of CASSANDRA-12673. The short of it is we no longer bind the local
side of a outbound connection as of CASSANDRA-12673, yet I mistakenly brought
that back (see
[{{NettyFactory#createOutboundBootstrap()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/NettyFactory.java#L337]).
I believe the most correct fix is just not setting the local address to bind to
for outbound connections, as that's bascially what CASSANDRA-12673 does.
Removing the local bind should resolve [~Lerh Low]'s error as well as eliminate
the regression against CASSANDRA-12673. However, we should also incorporate
[~Lerh Low]'s fix as well, to clarify the intent of which address we want to
'reference' (but not actually use) on the local side.
||14362||
|[branch|https://github.com/jasobrown/cassandra/tree/14362]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14362]|
tests are running now.
[~aweisberg] do you mind reviewing?
> Node unable to join cluster in trunk
>
>
> Key: CASSANDRA-14362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14362
> Project: Cassandra
> Issue Type: Bug
>Reporter: Lerh Chuan Low
>Assignee: Jason Brown
>Priority: Major
> Fix For: 4.0
>
>
> I'm not sure if anybody has tried using {{trunk}} and starting an actual EC2
> cluster, but with a 3 node setup that works on 3.11, it fails to work on
> {{trunk}}. I mistakenly stumbled into it while testing my own code changes.
> My setup is as follows:
> broadcast_rpc_address: publicIP
> broadcast_address: publicIP
> listen_address: omitted. Ends up as privateIP.
> Works on 3.11 just fine.
> On {{trunk}} though, it never works. My node is never able to join the
> cluster:
> {code}
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (-128373781239966537,-122439194129870521] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (6968670424536541270,6973888347502882935] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:42 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:42,298 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 26215173446ns > 50ns
> Apr 03 05:57:53 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:53,035 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 10736485907ns > 50ns
> Apr 03 05:58:30 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:30,790 Gossiper.java:814 - Gossip stage has 28 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 05:58:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:33,060 Gossiper.java:814 - Gossip stage has 20 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 06:04:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 06:04:33,826 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 400790432954ns > 50ns
> Apr 03 06:04:49
[jira] [Commented] (CASSANDRA-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426397#comment-16426397
]
Eric Evans commented on CASSANDRA-14355:
Our production cluster is on 3.11.0 and is running fine, yes. This staging
environment was first setup on 3.11.0 where these OOMs started, and has since
been upgraded to 3.11.2. Both versions OOM (regularly, on about 1.5 hour
intervals, in fact).
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426387#comment-16426387
]
Nate McCall commented on CASSANDRA-14355:
-
{quote}I am (so far) at a loss to understand what is different about this
environment.
{quote}
So other cluster(s) with the same version are running fine?
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-14362) Node unable to join cluster in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-14362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Brown updated CASSANDRA-14362:
Assignee: Jason Brown
Status: Patch Available (was: Open)
> Node unable to join cluster in trunk
>
>
> Key: CASSANDRA-14362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14362
> Project: Cassandra
> Issue Type: Bug
>Reporter: Lerh Chuan Low
>Assignee: Jason Brown
>Priority: Major
> Fix For: 4.0
>
>
> I'm not sure if anybody has tried using {{trunk}} and starting an actual EC2
> cluster, but with a 3 node setup that works on 3.11, it fails to work on
> {{trunk}}. I mistakenly stumbled into it while testing my own code changes.
> My setup is as follows:
> broadcast_rpc_address: publicIP
> broadcast_address: publicIP
> listen_address: omitted. Ends up as privateIP.
> Works on 3.11 just fine.
> On {{trunk}} though, it never works. My node is never able to join the
> cluster:
> {code}
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (-128373781239966537,-122439194129870521] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (6968670424536541270,6973888347502882935] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:42 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:42,298 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 26215173446ns > 50ns
> Apr 03 05:57:53 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:53,035 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 10736485907ns > 50ns
> Apr 03 05:58:30 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:30,790 Gossiper.java:814 - Gossip stage has 28 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 05:58:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:33,060 Gossiper.java:814 - Gossip stage has 20 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 06:04:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 06:04:33,826 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 400790432954ns > 50ns
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 06:04:49,133 Gossiper.java:814 - Gossip stage has 2 pending tasks;
> skipping status check (no nodes will be marked down)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: ERROR
> [StreamConnectionEstablisher:1] 2018-04-03 06:04:49,138
> StreamSession.java:524 - [Stream #d4cd6420-3703-11e8-a6a5-e51ddc10cfe6]
> Streaming error occurred on session with peer 52.88.241.181:7000
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: java.io.IOException: failed
> to connect to 52.88.241.181:7000 (STREAM) for streaming data
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.DefaultConnectionFactory.createConnection(DefaultConnectionFactory.java:98)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.DefaultConnectionFactory.createConnection(DefaultConnectionFactory.java:57)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender.createChannel(NettyStreamingMessageSender.java:183)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender.setupControlMessageChannel(NettyStreamingMessageSender.java:165)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender.sendMessage(NettyStreamingMessageSender.java:222)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender.initialize(NettyStreamingMessageSender.java:146)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.StreamSession.start(StreamSession.java:271)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.StreamCoordinator$StreamSessionConnector.run(StreamCoordinator.java:273)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> Apr 03 06:04:49 ip-10-0-47-122
[jira] [Commented] (CASSANDRA-14362) Node unable to join cluster in trunk
[
https://issues.apache.org/jira/browse/CASSANDRA-14362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426241#comment-16426241
]
Jason Brown commented on CASSANDRA-14362:
-
So it looks like when working on CASSANDRA-8457/CASSANDRA-12229, I introduced a
regression of CASSANDRA-12673. The short of it is we no longer bind the local
side of a outbound connection as of CASSANDRA-12673, yet I mistakenly brought
that back (see
[{{NettyFactory#createOutboundBootstrap()}}|https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/net/async/NettyFactory.java#L337]).
I believe the most correct fix is just not setting the local address to bind to
for outbound connections, as that's bascially what CASSANDRA-12673 does.
Removing the local bind should resolve [~Lerh Low]'s error as well as eliminate
the regression against CASSANDRA-12673. However, we should also incorporate
[~Lerh Low]'s fix as well, to clarify the intent of which address we want to
'reference' (but not actually use) on the local side.
||14362||
|[branch|https://github.com/jasobrown/cassandra/tree/14362]|
|[utests &
dtests|https://circleci.com/gh/jasobrown/workflows/cassandra/tree/14362]|
tests are running now.
[~aweisberg] do you mind reviewing?
> Node unable to join cluster in trunk
>
>
> Key: CASSANDRA-14362
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14362
> Project: Cassandra
> Issue Type: Bug
>Reporter: Lerh Chuan Low
>Priority: Major
> Fix For: 4.0
>
>
> I'm not sure if anybody has tried using {{trunk}} and starting an actual EC2
> cluster, but with a 3 node setup that works on 3.11, it fails to work on
> {{trunk}}. I mistakenly stumbled into it while testing my own code changes.
> My setup is as follows:
> broadcast_rpc_address: publicIP
> broadcast_address: publicIP
> listen_address: omitted. Ends up as privateIP.
> Works on 3.11 just fine.
> On {{trunk}} though, it never works. My node is never able to join the
> cluster:
> {code}
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (-128373781239966537,-122439194129870521] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:06 ip-10-0-47-122 cassandra[13914]: INFO [main] 2018-04-03
> 05:57:05,895 RangeStreamer.java:195 - Bootstrap: range
> (6968670424536541270,6973888347502882935] exists on 52.88.241.181:7000 for
> keyspace system_traces
> Apr 03 05:57:42 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:42,298 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 26215173446ns > 50ns
> Apr 03 05:57:53 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:57:53,035 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 10736485907ns > 50ns
> Apr 03 05:58:30 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:30,790 Gossiper.java:814 - Gossip stage has 28 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 05:58:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 05:58:33,060 Gossiper.java:814 - Gossip stage has 20 pending
> tasks; skipping status check (no nodes will be marked down)
> Apr 03 06:04:33 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 06:04:33,826 FailureDetector.java:324 - Not marking nodes down due
> to local pause of 400790432954ns > 50ns
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: WARN [GossipTasks:1]
> 2018-04-03 06:04:49,133 Gossiper.java:814 - Gossip stage has 2 pending tasks;
> skipping status check (no nodes will be marked down)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: ERROR
> [StreamConnectionEstablisher:1] 2018-04-03 06:04:49,138
> StreamSession.java:524 - [Stream #d4cd6420-3703-11e8-a6a5-e51ddc10cfe6]
> Streaming error occurred on session with peer 52.88.241.181:7000
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: java.io.IOException: failed
> to connect to 52.88.241.181:7000 (STREAM) for streaming data
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.DefaultConnectionFactory.createConnection(DefaultConnectionFactory.java:98)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.DefaultConnectionFactory.createConnection(DefaultConnectionFactory.java:57)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
> org.apache.cassandra.streaming.async.NettyStreamingMessageSender.createChannel(NettyStreamingMessageSender.java:183)
> Apr 03 06:04:49 ip-10-0-47-122 cassandra[13914]: at
>
[jira] [Commented] (CASSANDRA-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426179#comment-16426179
]
Eric Evans commented on CASSANDRA-14355:
Also, I can make a heap available, but be warned, they are 12GB in size.
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426178#comment-16426178
]
Eric Evans commented on CASSANDRA-14355:
{quote}[~urandom] Did this just start happening again or is this a continuation
of the issues you saw with CASSANDRA-13754?
{quote}
This is happening in a newly minted staging cluster, and is (readily)
reproducible on both the same 3.11.0 build we use in production, and 3.11.2. I
am (so far) at a loss to understand what is different about this environment.
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426118#comment-16426118
]
Nate McCall commented on CASSANDRA-14355:
-
[~urandom] Did this just start happening again or is this a continuation of the
issues you saw with CASSANDRA-13754?
Also, [~tsteinmaurer] this issue looks different from what you experienced in
CASSANDRA-13929, but have you all encountered anything like this before?
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-14355) Memory leak
[
https://issues.apache.org/jira/browse/CASSANDRA-14355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Evans updated CASSANDRA-14355:
---
Attachment: 03_Screenshot from 2018-04-04 14-24-50.png
02_Screenshot from 2018-04-04 14-28-33.png
01_Screenshot from 2018-04-04 14-24-00.png
> Memory leak
> ---
>
> Key: CASSANDRA-14355
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14355
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian Jessie, OpenJDK 1.8.0_151
>Reporter: Eric Evans
>Priority: Major
> Fix For: 3.11.3
>
> Attachments: 01_Screenshot from 2018-04-04 14-24-00.png,
> 02_Screenshot from 2018-04-04 14-28-33.png, 03_Screenshot from 2018-04-04
> 14-24-50.png
>
>
> We're seeing regular, frequent {{OutOfMemoryError}} exceptions. Similar to
> CASSANDRA-13754, an analysis of the heap dumps shows the heap consumed by the
> {{threadLocals}} member of the instances of
> {{io.netty.util.concurrent.FastThreadLocalThread}}.
--
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-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425952#comment-16425952 ] Chris Lohfink commented on CASSANDRA-7622: -- Well with my proposed implementation there is only a single system non-replicated keyspace containing virtual tables and you cant create them so thats not really an issue. When we add support to allow people create virtual tables that could easily be limited to local replicated or a keyspace flagged with virtual. With this implementation worth noting that theres nothing preventing an implementor from using the keyspace's replication factor and distributing accordingly, but the in memory virtual table used in the system keyspace are all setup for local replication, so the limitation (on a local RF) on create could be placed on that implementation of VirtualTable. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Chris Lohfink >Priority: Major > Fix For: 4.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- 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-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425902#comment-16425902 ] Jeremiah Jordan commented on CASSANDRA-7622: Since we specify replication at the keyspace level, I also think it would be very confusing to have non-replicated virtual tables mixed in to some other keyspace. Those replication settings are used by drivers and other tools to figure out how to handle the tables that use them, it makes the most sense to me for virtual tables to follow the same logic, rather than becoming even more special. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Chris Lohfink >Priority: Major > Fix For: 4.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- 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] [Comment Edited] (CASSANDRA-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425891#comment-16425891
]
Edward Ribeiro edited comment on CASSANDRA-13891 at 4/4/18 5:25 PM:
[~jasobrown], the second test I created below fails with
NullPointerException, but everything passes after the little fix. FYI,
the test that fails on 2.2 and 3.0 is below:
{code:java}
execute("INSERT INTO %s (k, frozenmapval) VALUES (?, fromJson(?))", 0, null);
assertRows(execute("SELECT k, frozenmapval FROM %s WHERE k = ?", 0), row(0,
null));{code}
I have open the following PRs targeting 2.2 and 3.0, respectively. I don't have
access to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
was (Author: eribeiro):
[~jasobrown], the second test I created below fails with
\{{NullPointerException}}, but everything passes after the little fix. I have
open the following PRs targeting 2.2 and 3.0, respectively. I don't have access
to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425891#comment-16425891
]
Edward Ribeiro commented on CASSANDRA-13891:
[~jasobrown], the second test I created below fails with
\{{NullPointerException}}, but everything passes after the little fix. I have
open the following PRs targeting 2.2 and 3.0, respectively. I don't have access
to a CI so it would be nice if you could run those tests. :)
[https://github.com/apache/cassandra/pull/215]
[https://github.com/apache/cassandra/pull/216]
Oh, and let me know if I missed something, please.
Thanks!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425814#comment-16425814
]
Jon Haddad commented on CASSANDRA-14361:
{quote}
Would it be worth adding some info/debug level logging around what IPs got
resolved for each time getSeeds() gets called?
{quote}
Yes, I think that's a good idea. Maybe WARN if we're getting more than 20
seeds back. Under that I don't think the optimization matters, above that,
it's probably not great.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425809#comment-16425809 ] Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 4:30 PM: -- I would argue that you need to be intentional about your DNS records, but I'm willing to concede that it moves config further away from the system which can hide the reason for behavior. Would it be worth adding some info/debug level logging around what IPs got resolved for each time getSeeds() gets called? At least that way the behavior of what gets looked up is observable and the answer to any potential WTFs is in the logs. was (Author: benbromhead): I would argue you need to be intentional about your DNS records, but I'm willing to concede that it moves config further away from the system which can hide the reason for behavior. Would it be worth adding some info/debug level logging around what IPs got resolved for each time getSeeds() gets called? At least that way the behavior of what gets looked up is observable and the answer to any potential WTFs is in the logs. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425809#comment-16425809 ] Ben Bromhead commented on CASSANDRA-14361: -- I would argue you need to be intentional about your DNS records, but I'm willing to concede that it moves config further away from the system which can hide the reason for behavior. Would it be worth adding some info/debug level logging around what IPs got resolved for each time getSeeds() gets called? At least that way the behavior of what gets looked up is observable and the answer to any potential WTFs is in the logs. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425769#comment-16425769 ] Chris Lohfink commented on CASSANDRA-7622: -- With the implementation provided there are no if-else conditions in the Keyspace.apply because the handoff to the virtual logic is handled essentially as soon as the query has been parsed and identified as going to that virtual table. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Chris Lohfink >Priority: Major > Fix For: 4.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- 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-7622) Implement virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425756#comment-16425756
]
Aleksey Yeschenko commented on CASSANDRA-7622:
--
The right level of abstraction, for both this and pluggable storage, is on
keyspace level. The basic write unit we have is a {{Mutation}}, and you have to
accept this. What would not be acceptable is if-else conditions in
{{Keyspace.apply()}} depending on what the kind of table this is.
Additionally, all tables in a keyspace by definition share the same replication
strategy and params, and I just don't see how you can mix and match regular and
virtual ones in the same keyspace.
> Implement virtual tables
>
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
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-14281) Improve LatencyMetrics performance by reducing write path processing
[ https://issues.apache.org/jira/browse/CASSANDRA-14281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425728#comment-16425728 ] Chris Lohfink commented on CASSANDRA-14281: --- [~burmanm] can you make a attach a link to branch or make pr for the bot to do it (just to make it easier). also since this is a perf patch can you post the difference with cassandra-stress as full benchmark instead of just the jmh ones? > Improve LatencyMetrics performance by reducing write path processing > > > Key: CASSANDRA-14281 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14281 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Michael Burman >Assignee: Michael Burman >Priority: Major > > Currently for each write/read/rangequery/CAS touching the CFS we write a > latency metric which takes a lot of processing time (up to 66% of the total > processing time if the update was empty). > The way latencies are recorded is to use both a dropwizard "Timer" as well as > "Counter". Latter is used for totalLatency and the previous is decaying > metric for rates and certain percentile metrics. We then replicate all of > these CFS writes to the KeyspaceMetrics and globalWriteLatencies. > Instead of doing this on the write phase we should merge the metrics when > they're read. This is much less common occurrence and thus we save a lot of > CPU time in total. This also speeds up the write path. > Currently, the DecayingEstimatedHistogramReservoir acquires a lock for each > update operation, which causes a contention if there are more than one thread > updating the histogram. This impacts scalability when using larger machines. > We should make it lock-free as much as possible and also avoid a single > CAS-update from blocking all the concurrent threads from making an update. -- 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] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425723#comment-16425723 ] Jon Haddad edited comment on CASSANDRA-14361 at 4/4/18 3:31 PM: I agree with you, you could *explicitly* put 1000 seeds in there. Would you expect there to be 1000 potential seeds in your gossip list by putting 1 thing in the seed list? People don't even mostly know about this behavior. I'm not sure it's optimal, and I'm not arguing against changing it, I'm just pointing it out and saying it's worth a discussion. A point against it being, the new behavior might be a bit surprising (and maybe it doesn't actually change at all) was (Author: rustyrazorblade): I agree with you, you could *explicitly* put 1000 seeds in there. Would you expect there to be 1000 potential seeds in your gossip list by putting 1 thing in the seed list? People don't even mostly know about this behavior. I'm not sure it's optimal, and I'm not arguing against changing it, I'm just pointing it out and saying it's worth a discussion. A point against it being, the new behavior might be a bit surprising. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425723#comment-16425723 ] Jon Haddad commented on CASSANDRA-14361: I agree with you, you could *explicitly* put 1000 seeds in there. Would you expect there to be 1000 potential seeds in your gossip list by putting 1 thing in the seed list? People don't even mostly know about this behavior. I'm not sure it's optimal, and I'm not arguing against changing it, I'm just pointing it out and saying it's worth a discussion. A point against it being, the new behavior might be a bit surprising. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425713#comment-16425713 ] Ben Bromhead commented on CASSANDRA-14361: -- Currently nothing stops users adding as many seeds as they want to the current implementation. So this change doesn't make the situation any worse. I do agree with you that gossip convergence based on the information provided in the seed list needs to be further explored, but I don't think this ticket is the right place to address it. I would also argue that the seed providers only job is to act as an external oracle about membership independent of Gossip. Based on the current interface contract the seed provider should be able to return 1 or 1000 seeds, then whatever consumes that seeds list needs to make the correct decision about how to use that list. However that's just my opinion and one I'm not inclined to argue that vigorously :) > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425693#comment-16425693
]
Benjamin Lerer commented on CASSANDRA-14286:
Patches and test results look fine. Thanks.
> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
>
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.Collections$SingletonList.get(Collections.java:4815)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
> ~[na:1.8.0_151]
> at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
> at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
> at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
> at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}
--
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] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425647#comment-16425647
]
Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 3:15 PM:
--
{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise
operators will have to do a rolling restart of the cluster each time the seed
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
was (Author: benbromhead):
{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise
operators will have to do a rolling restart of the cluster each time the seed
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[ https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425664#comment-16425664 ] Jon Haddad commented on CASSANDRA-14361: Well, the behavior can be a bit surprising, and possibly could affect gossip convergence. The seed gossip round is to accelerate convergence time, although I've never seen it proven that it works as advertised. It might be a good idea to cap the number of seeds we allow gossip to use there. There has been talk of a changing the seed round behavior in CASSANDRA-9206, might be worth a read. Adding [~jasobrown]. > Allow SimpleSeedProvider to resolve multiple IPs per DNS name > - > > Key: CASSANDRA-14361 > URL: https://issues.apache.org/jira/browse/CASSANDRA-14361 > Project: Cassandra > Issue Type: Improvement > Components: Configuration >Reporter: Ben Bromhead >Assignee: Ben Bromhead >Priority: Minor > Fix For: 4.0 > > > Currently SimpleSeedProvider can accept a comma separated string of IPs or > hostnames as the set of Cassandra seeds. hostnames are resolved via > InetAddress.getByName, which will only return the first IP associated with an > A, or CNAME record. > By changing to InetAddress.getAllByName, existing behavior is preserved, but > now Cassandra can discover multiple IP address per record, allowing seed > discovery by DNS to be a little easier. > Some examples of improved workflows with this change include: > * specify the DNS name of a headless service in Kubernetes which will > resolve to all IP addresses of pods within that service. > * seed discovery for multi-region clusters via AWS route53, AzureDNS etc > * Other common DNS service discovery mechanisms. > The only behavior this is likely to impact would be where users are relying > on the fact that getByName only returns a single IP address. > I can't imagine any scenario where that is a sane choice. Even when that > choice has been made, it only impacts the first startup of Cassandra and > would not be on any critical path. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425647#comment-16425647
]
Ben Bromhead commented on CASSANDRA-14361:
--
{quote}
JVM property networkaddress.cache.ttl must be set otherwise operators
will have to do a rolling restart of the cluster each time the seed list
changes (unless default is not -1 on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}
This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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] [Comment Edited] (CASSANDRA-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425647#comment-16425647
]
Ben Bromhead edited comment on CASSANDRA-14361 at 4/4/18 2:52 PM:
--
{quote}JVM property {{networkaddress.cache.ttl}} must be set otherwise
operators will have to do a rolling restart of the cluster each time the seed
list changes (unless default is not {{-1}} on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
was (Author: benbromhead):
{quote}
JVM property networkaddress.cache.ttl must be set otherwise operators
will have to do a rolling restart of the cluster each time the seed list
changes (unless default is not -1 on their platforms).
{quote}
Caching behavior remains the same, given operators relying on hostnames in the
seed list would need to be aware of this anyway, whether it looks up one IP or
multiple. Also the JVM will only cache forever by default if a security manager
is installed. If a security manager is not installed each specific JVM
implementations can have a potentially different TTL, but a defined TTL
nonetheless. See
[https://docs.oracle.com/javase/8/docs/technotes/guides/net/properties.html].
{quote}
This would also affect the third gossip round:
[https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185]
{quote}
Ah, of course.
If you are already using hostnames in the seed list, the behavior would still
be the same? Other than your list of seeds potentially containing seed IPs you
might not expect, if you are returning multiple IPs per A record, but not
relying on the behavior. Resulting in potentially more gossip rounds to hit the
IP you used to expect?
I've marked this as a 4.0 patch, so I think a change in behavior would be fine.
I've created another ticket
https://issues.apache.org/jira/browse/CASSANDRA-14364 to document seed behavior
with relation to the third gossip round and DNS (including caching) behavior.
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
This message was sent by Atlassian
[jira] [Created] (CASSANDRA-14364) Update Seed provider documentation
Ben Bromhead created CASSANDRA-14364: Summary: Update Seed provider documentation Key: CASSANDRA-14364 URL: https://issues.apache.org/jira/browse/CASSANDRA-14364 Project: Cassandra Issue Type: Improvement Components: Documentation and Website Reporter: Ben Bromhead Update documentation to describe how Cassandra uses the seed list. Include details about nuances of using DNS hostnames vs IP addresses. [http://cassandra.apache.org/doc/latest/configuration/cassandra_config_file.html#seed-provider] -- 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-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425639#comment-16425639 ] Jon Haddad commented on CASSANDRA-7622: --- I agree with [~burmanm]. Requiring the keyspace to be a virtual one seems unnecessary and even weird, from a user perspective. > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Chris Lohfink >Priority: Major > Fix For: 4.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425610#comment-16425610
]
Jon Haddad commented on CASSANDRA-14361:
{quote}
I can't imagine any scenario where that is a sane choice. Even when that choice
has been made, it only impacts the first startup of Cassandra and would not be
on any critical path.
{quote}
This would also affect the third gossip round:
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/gms/Gossiper.java#L185
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425567#comment-16425567
]
Benjamin Lerer commented on CASSANDRA-13891:
Thanks.
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425553#comment-16425553
]
Jason Brown commented on CASSANDRA-13891:
-
bq. I would prefer if we added the unit tests to all the versions.
This is fair enough. I'll wait for the results of [~eribeiro]'s testing and
then do the backporting of the required parts.
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425546#comment-16425546
]
Edward Ribeiro commented on CASSANDRA-13891:
Sure! Gonna try to repro on 2.2 and 3.0 for double check, no problem. Thanks
again, Jason!
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425544#comment-16425544
]
Benjamin Lerer commented on CASSANDRA-13891:
[~jasobrown] I did not tested it on 2.2 and 3.0. I just assumed that we had
this bug since the begining. Nevertheless, I would prefer if we added the unit
tests to all the versions.
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
]
Francisco Fernandez edited comment on CASSANDRA-14286 at 4/4/18 1:50 PM:
-
The problem was that columns were serialized as json and then discarded, while
{{OrderingComparator}} expected those columns to be present. With this patch,
all columns are present and only the json column is sent back to clients. It
uses the same mechanism as the regular ordering of non-selected columns.
[Patch
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
[Patch
3.0|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.0?expand=1]
[Patch
3.11|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-3.11?expand=1]
[Patch
trunk|https://github.com/apache/cassandra/compare/trunk...fcofdez:14286-trunk?expand=1]
was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while
{{OrderingComparator}} expected those columns to be present. With this patch,
all columns are present and only the json column is sent back to clients. It
uses the same mechanism as the regular ordering of non-selected columns.
[Patch
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
[Patch 3.0|https://github.com/fcofdez/cassandra/tree/14286-3.0]
[Patch 3.11|https://github.com/fcofdez/cassandra/tree/14286-3.11]
[Patch trunk|https://github.com/fcofdez/cassandra/tree/14286-trunk]
> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
>
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.Collections$SingletonList.get(Collections.java:4815)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
> ~[na:1.8.0_151]
> at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
> at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
> at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
> at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}
--
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] [Comment Edited] (CASSANDRA-14286) IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
[
https://issues.apache.org/jira/browse/CASSANDRA-14286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16409339#comment-16409339
]
Francisco Fernandez edited comment on CASSANDRA-14286 at 4/4/18 1:49 PM:
-
The problem was that columns were serialized as json and then discarded, while
{{OrderingComparator}} expected those columns to be present. With this patch,
all columns are present and only the json column is sent back to clients. It
uses the same mechanism as the regular ordering of non-selected columns.
[Patch
2.2|https://github.com/apache/cassandra/compare/trunk...blerer:14286-2.2-review]
[Patch 3.0|https://github.com/fcofdez/cassandra/tree/14286-3.0]
[Patch 3.11|https://github.com/fcofdez/cassandra/tree/14286-3.11]
[Patch trunk|https://github.com/fcofdez/cassandra/tree/14286-trunk]
was (Author: fcofdezc):
The problem was that columns were serialized as json and then discarded, while
{{OrderingComparator}} expected those columns to be present. With this patch,
all columns are present and only the json column is sent back to clients. It
uses the same mechanism as the regular ordering of non-selected columns.
[Patch|https://github.com/apache/cassandra/compare/cassandra-2.2...fcofdez:CASSANDRA-14286-2?expand=1]
> IndexOutOfBoundsException with SELECT JSON using IN and ORDER BY
>
>
> Key: CASSANDRA-14286
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14286
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Kubernetes cluster using cassandra:3.11.1 Docker image.
>Reporter: Szymon Acedański
>Assignee: Francisco Fernandez
>Priority: Major
> Attachments: orderbug-traceback.txt
>
>
> When running the following code:
> {code}
> public class CassandraJsonOrderingBug {
> public static void main(String[] args) {
> Session session = CassandraFactory.getSession();
> session.execute("CREATE TABLE thebug ( PRIMARY KEY (a, b), a INT, b
> INT)");
> try {
> session.execute("INSERT INTO thebug (a, b) VALUES (20, 30)");
> session.execute("INSERT INTO thebug (a, b) VALUES (100, 200)");
> Statement statement = new SimpleStatement("SELECT JSON a, b FROM
> thebug WHERE a IN (20, 100) ORDER BY b");
> statement.setFetchSize(Integer.MAX_VALUE);
> for (Row w: session.execute(statement)) {
> System.out.println(w.toString());
> }
> } finally {
> session.execute("DROP TABLE thebug");
> }
> }
> }
> {code}
> The following exception is thrown server-side:
> {noformat}
> java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.Collections$SingletonList.get(Collections.java:4815)
> ~[na:1.8.0_151]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1297)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at
> org.apache.cassandra.cql3.statements.SelectStatement$SingleColumnComparator.compare(SelectStatement.java:1284)
> ~[apache-cassandra-3.11.1.jar:3.11.1]
> at java.util.TimSort.countRunAndMakeAscending(TimSort.java:355)
> ~[na:1.8.0_151]
> at java.util.TimSort.sort(TimSort.java:220) ~[na:1.8.0_151]
> at java.util.Arrays.sort(Arrays.java:1512) ~[na:1.8.0_151]
> at java.util.ArrayList.sort(ArrayList.java:1460) ~[na:1.8.0_151]
> at java.util.Collections.sort(Collections.java:175) ~[na:1.8.0_151]
> {noformat}
> (full traceback attached)
> The accessed index is the index of the sorted column in the SELECT JSON
> fields list.
> Similarly, if the select clause is changed to
> SELECT JSON b, a FROM thebug WHERE a IN (20, 100) ORDER BY b
> then the query finishes, but the output is sorted incorrectly (by textual
> JSON representation):
> {noformat}
> Row[{"b": 200, "a": 100}]
> Row[{"b": 30, "a": 20}]
> {noformat}
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425535#comment-16425535
]
Jason Brown commented on CASSANDRA-13891:
-
[~blerer] The bug didn't happen on 2.2 or 3.0 when I tried it.
[~eribeiro] Can you confirm if the bug happens on 2.2 and 3.0? If so, I'll
backport the patch.
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-13891) fromJson(null) throws java.lang.NullPointerException on Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-13891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Lerer reopened CASSANDRA-13891:
Reproduced In: 3.11.0, 3.9 (was: 3.9, 3.11.0)
As [~eribeiro] pointed it out we also need patches for 2.2 and 3.0.
> fromJson(null) throws java.lang.NullPointerException on Cassandra
> -
>
> Key: CASSANDRA-13891
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13891
> Project: Cassandra
> Issue Type: Bug
> Components: CQL
> Environment: Cassandra 3.11
>Reporter: Marcel Villet
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 4.0, 3.11.3
>
> Attachments: CASSANDRA-13891.patch
>
>
> Basically, {{fromJson}} throws a {{java.lang.NullPointerException}} when NULL
> is passed, instead of just returning a NULL itself. Say I create a UDT and a
> table as follows:
> {code:java}
> create type type1
> (
> id int,
> name text
> );
> create table table1
> (
> id int,
> t FROZEN,
> primary key (id)
> );{code}
> And then try and insert a row as such:
> {{insert into table1 (id, t) VALUES (1, fromJson(null));}}
> I get the error: {{java.lang.NullPointerException}}
> This works as expected: {{insert into table1 (id, t) VALUES (1, null);}}
> Programmatically, one does not always know when a UDT will be null, hence me
> expecting {{fromJson}} to just return NULL.
--
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-7622) Implement virtual tables
[ https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425478#comment-16425478 ] Michael Burman commented on CASSANDRA-7622: --- My personal view would be to avoid keyspace per type of origin and instead concentrate on the data itself. Monitoring "virtual tables" for example should probably live in the SystemKeyspace (or monitoring, but I'm not sure if we need so many internal keyspaces). Although this opinion is affected by the fact that I got so used to using SQL Server's DMVs, but they do their job quite well (they use the table naming to indicate information type also - but that's outside this ticket). > Implement virtual tables > > > Key: CASSANDRA-7622 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7622 > Project: Cassandra > Issue Type: Improvement > Components: CQL >Reporter: Tupshin Harper >Assignee: Chris Lohfink >Priority: Major > Fix For: 4.x > > > There are a variety of reasons to want virtual tables, which would be any > table that would be backed by an API, rather than data explicitly managed and > stored as sstables. > One possible use case would be to expose JMX data through CQL as a > resurrection of CASSANDRA-3527. > Another is a more general framework to implement the ability to expose yaml > configuration information. So it would be an alternate approach to > CASSANDRA-7370. > A possible implementation would be in terms of CASSANDRA-7443, but I am not > presupposing. -- 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] [Comment Edited] (CASSANDRA-13851) Allow existing nodes to use all peers in shadow round
[ https://issues.apache.org/jira/browse/CASSANDRA-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425315#comment-16425315 ] Kurt Greaves edited comment on CASSANDRA-13851 at 4/4/18 10:46 AM: --- [~beobal] Sorry for the delay, went on holidays and just got around to fixing the test. Turns out it was failing because the log message changed ever so slightly after CASSANDRA-7544 by removing the leading slash on the IP address. I also applied your dtest changes to my branch and made some minor formatting changes. |[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...kgreav:3.11-13851]|[utests|https://circleci.com/gh/kgreav/cassandra/150]| |[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:13851-trunk]|[utests|https://circleci.com/gh/kgreav/cassandra/148]| |[dtest|https://github.com/apache/cassandra-dtest/compare/master...kgreav:13851]| was (Author: kurtg): [~beobal] Sorry for the delay, went on holidays and just got around to fixing the test. Turns out it was failing because the log message changed ever so slightly after CASSANDRA-7544 by removing the leading slash on the IP address. I also applied your dtest changes to my branch and made some minor formatting changes. |[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...kgreav:3.11-13851]|[utests|https://circleci.com/gh/kgreav/cassandra/150]| |[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:13851-trunk]|[utests|https://circleci.com/gh/kgreav/cassandra/148]| > Allow existing nodes to use all peers in shadow round > - > > Key: CASSANDRA-13851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13851 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle >Reporter: Kurt Greaves >Assignee: Kurt Greaves >Priority: Major > Fix For: 3.11.x, 4.x > > > In CASSANDRA-10134 we made collision checks necessary on every startup. A > side-effect was introduced that then requires a nodes seeds to be contacted > on every startup. Prior to this change an existing node could start up > regardless whether it could contact a seed node or not (because > checkForEndpointCollision() was only called for bootstrapping nodes). > Now if a nodes seeds are removed/deleted/fail it will no longer be able to > start up until live seeds are configured (or itself is made a seed), even > though it already knows about the rest of the ring. This is inconvenient for > operators and has the potential to cause some nasty surprises and increase > downtime. > One solution would be to use all a nodes existing peers as seeds in the > shadow round. Not a Gossip guru though so not sure of implications. -- 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] [Comment Edited] (CASSANDRA-13851) Allow existing nodes to use all peers in shadow round
[ https://issues.apache.org/jira/browse/CASSANDRA-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425315#comment-16425315 ] Kurt Greaves edited comment on CASSANDRA-13851 at 4/4/18 10:43 AM: --- [~beobal] Sorry for the delay, went on holidays and just got around to fixing the test. Turns out it was failing because the log message changed ever so slightly after CASSANDRA-7544 by removing the leading slash on the IP address. I also applied your dtest changes to my branch and made some minor formatting changes. |[3.11|https://github.com/apache/cassandra/compare/cassandra-3.11...kgreav:3.11-13851]|[utests|https://circleci.com/gh/kgreav/cassandra/150]| |[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:13851-trunk]|[utests|https://circleci.com/gh/kgreav/cassandra/148]| was (Author: kurtg): [~beobal] Sorry for the delay, went on holidays and just got around to fixing the test. Turns out it was failing because the log message changed ever so slightly after CASSANDRA-7544 by removing the leading slash on the IP address. I also applied your dtest changes to my branch and made some minor formatting changes. |[3.11|https://github.com/apache/cassandra/compare/trunk...kgreav:3.11-13851]|[utests|https://circleci.com/gh/kgreav/cassandra/150]| |[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:13851-trunk]|[utests|https://circleci.com/gh/kgreav/cassandra/148]| > Allow existing nodes to use all peers in shadow round > - > > Key: CASSANDRA-13851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13851 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle >Reporter: Kurt Greaves >Assignee: Kurt Greaves >Priority: Major > Fix For: 3.11.x, 4.x > > > In CASSANDRA-10134 we made collision checks necessary on every startup. A > side-effect was introduced that then requires a nodes seeds to be contacted > on every startup. Prior to this change an existing node could start up > regardless whether it could contact a seed node or not (because > checkForEndpointCollision() was only called for bootstrapping nodes). > Now if a nodes seeds are removed/deleted/fail it will no longer be able to > start up until live seeds are configured (or itself is made a seed), even > though it already knows about the rest of the ring. This is inconvenient for > operators and has the potential to cause some nasty surprises and increase > downtime. > One solution would be to use all a nodes existing peers as seeds in the > shadow round. Not a Gossip guru though so not sure of implications. -- 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-13851) Allow existing nodes to use all peers in shadow round
[ https://issues.apache.org/jira/browse/CASSANDRA-13851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425315#comment-16425315 ] Kurt Greaves commented on CASSANDRA-13851: -- [~beobal] Sorry for the delay, went on holidays and just got around to fixing the test. Turns out it was failing because the log message changed ever so slightly after CASSANDRA-7544 by removing the leading slash on the IP address. I also applied your dtest changes to my branch and made some minor formatting changes. |[3.11|https://github.com/apache/cassandra/compare/trunk...kgreav:3.11-13851]|[utests|https://circleci.com/gh/kgreav/cassandra/150]| |[trunk|https://github.com/apache/cassandra/compare/trunk...kgreav:13851-trunk]|[utests|https://circleci.com/gh/kgreav/cassandra/148]| > Allow existing nodes to use all peers in shadow round > - > > Key: CASSANDRA-13851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-13851 > Project: Cassandra > Issue Type: Bug > Components: Lifecycle >Reporter: Kurt Greaves >Assignee: Kurt Greaves >Priority: Major > Fix For: 3.11.x, 4.x > > > In CASSANDRA-10134 we made collision checks necessary on every startup. A > side-effect was introduced that then requires a nodes seeds to be contacted > on every startup. Prior to this change an existing node could start up > regardless whether it could contact a seed node or not (because > checkForEndpointCollision() was only called for bootstrapping nodes). > Now if a nodes seeds are removed/deleted/fail it will no longer be able to > start up until live seeds are configured (or itself is made a seed), even > though it already knows about the rest of the ring. This is inconvenient for > operators and has the potential to cause some nasty surprises and increase > downtime. > One solution would be to use all a nodes existing peers as seeds in the > shadow round. Not a Gossip guru though so not sure of implications. -- 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-14361) Allow SimpleSeedProvider to resolve multiple IPs per DNS name
[
https://issues.apache.org/jira/browse/CASSANDRA-14361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425244#comment-16425244
]
Romain Hardouin commented on CASSANDRA-14361:
-
JVM property {{networkaddress.cache.ttl}} must be set otherwise operators will
have to do a rolling restart of the cluster each time the seed list changes
(unless default is not {{-1}} on their platforms).
> Allow SimpleSeedProvider to resolve multiple IPs per DNS name
> -
>
> Key: CASSANDRA-14361
> URL: https://issues.apache.org/jira/browse/CASSANDRA-14361
> Project: Cassandra
> Issue Type: Improvement
> Components: Configuration
>Reporter: Ben Bromhead
>Assignee: Ben Bromhead
>Priority: Minor
> Fix For: 4.0
>
>
> Currently SimpleSeedProvider can accept a comma separated string of IPs or
> hostnames as the set of Cassandra seeds. hostnames are resolved via
> InetAddress.getByName, which will only return the first IP associated with an
> A, or CNAME record.
> By changing to InetAddress.getAllByName, existing behavior is preserved, but
> now Cassandra can discover multiple IP address per record, allowing seed
> discovery by DNS to be a little easier.
> Some examples of improved workflows with this change include:
> * specify the DNS name of a headless service in Kubernetes which will
> resolve to all IP addresses of pods within that service.
> * seed discovery for multi-region clusters via AWS route53, AzureDNS etc
> * Other common DNS service discovery mechanisms.
> The only behavior this is likely to impact would be where users are relying
> on the fact that getByName only returns a single IP address.
> I can't imagine any scenario where that is a sane choice. Even when that
> choice has been made, it only impacts the first startup of Cassandra and
> would not be on any critical path.
--
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-7622) Implement virtual tables
[
https://issues.apache.org/jira/browse/CASSANDRA-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425076#comment-16425076
]
Dinesh Joshi commented on CASSANDRA-7622:
-
[~cnlwsu], I spent some time looking at the patch. My initial thoughts on the
implementation are that we should probably have a separate {{VirtualKeyspace}}
like we have a {{SystemKeyspace}}. This will allow us to isolate / namespace
{{VirtualTables}}. We can always change this if needed. One of the advantage, I
think, is that this keyspace can become available for serving sooner (we would
ofcourse need to change the bootstrap for this to work). If we're exposing
metrics or other internal state then this would be very helpful. What do you
think?
> Implement virtual tables
>
>
> Key: CASSANDRA-7622
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
> Project: Cassandra
> Issue Type: Improvement
> Components: CQL
>Reporter: Tupshin Harper
>Assignee: Chris Lohfink
>Priority: Major
> Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any
> table that would be backed by an API, rather than data explicitly managed and
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml
> configuration information. So it would be an alternate approach to
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not
> presupposing.
--
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
