[jira] [Created] (CASSANDRA-8024) No boot finished or ready message anymore upon startup completion to CLI
Karl Mueller created CASSANDRA-8024:
---
Summary: No boot finished or ready message anymore upon startup
completion to CLI
Key: CASSANDRA-8024
URL: https://issues.apache.org/jira/browse/CASSANDRA-8024
Project: Cassandra
Issue Type: Bug
Environment: Cassandra 2.0.10
Reporter: Karl Mueller
Priority: Trivial
This is trivial, but cassandra logs the following to its log:
...
INFO [main] 2014-09-29 23:10:35,793 CassandraDaemon.java (line 575) No gossip
backlog; proceeding
INFO [main] 2014-09-29 23:10:35,979 Server.java (line 156) Starting listening
for CQL clients on kaos-cass00.sv.walmartlabs.com/10.93.12.10:9042...
INFO [main] 2014-09-29 23:10:36,048 ThriftServer.java (line 99) Using
TFramedTransport with a max frame size of 15728640 bytes.
However, on the command line I only see:
INFO 23:10:30,005 Compacted 4 sstables to
[/data2/data-cassandra/system/compactions_in_progress/system-compactions_in_progress-jb-67,].
1,333 bytes to 962 (~72% of original) in 32ms = 0.028670MB/s. 15 total
partitions merged to 12. Partition merge counts were {1:11, 2:2, }
INFO 23:10:35,793 No gossip backlog; proceeding
I would be nice if the "Starting listening for.." or some other "startup
complete" message went to the command line STDOUT. There used to be one, I
think, but there isn't anymore.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152770#comment-14152770 ] sankalp kohli commented on CASSANDRA-6246: -- Yes make sense. > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8023) DESCRIBE KEYSPACES / KEYSPACE no longer works with Cassandra 2.1 and cqlsh
Matthew O'Riordan created CASSANDRA-8023: Summary: DESCRIBE KEYSPACES / KEYSPACE no longer works with Cassandra 2.1 and cqlsh Key: CASSANDRA-8023 URL: https://issues.apache.org/jira/browse/CASSANDRA-8023 Project: Cassandra Issue Type: Bug Components: Tools Environment: Ubuntu 14.04, running in a Docker container with Ubuntu 14.04 Reporter: Matthew O'Riordan Fix For: 2.1.0 Connecting to my Cassandra 2.1 cluster with the new 5.0.1 version of cqlsh, when I run DESCRIBE KEYSPACES I am told there are no keyspaces. ``` cqlsh> describe keyspaces describe keyspaces ``` Yet if I connect to that same cluster with version 4 of cqlsh it works fine, I can query the keyspaces, and if I run the query manually `select * from system.schema_keyspaces` I am given a list of keyspaces. `DESCRIBE KEYSPACE` also fails with the new cqlsh tool, yet works with version 4. ``` cqlsh>use mykeyspace; cqlsh:mykeyspace> describe keyspace; describe keyspace; Keyspace 'ably_sandbox_0' not found. ``` -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8011) Fail on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152677#comment-14152677
]
sankalp kohli commented on CASSANDRA-8011:
--
You are assigning the variable in DatabaseDescriptor. Why not do as it is done
for similar stuff like tombstone_failure_threshold.
In Config, you can make public volatile int batch_size_fail_threshold_in_kb =
50 like it is done for tombstone_failure_threshold.
> Fail on large batch sizes
> --
>
> Key: CASSANDRA-8011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 8011-trunk-v2.txt, 8011-trunk.txt
>
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
> Just education alone is not going to stop some of the largest batch sizes
> from being used. Just like we have a tombstone fail threshold, I propose that
> we have a batch size fail threshold.
> Maybe 10x warn?
> {{batch_fail_threshold: 50k}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-6904) commitlog segments may not be archived after restart
[ https://issues.apache.org/jira/browse/CASSANDRA-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6904: -- Reviewer: Jonathan Ellis (was: Benedict) > commitlog segments may not be archived after restart > > > Key: CASSANDRA-6904 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6904 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Sam Tunnicliffe > Fix For: 2.0.11, 2.1.1 > > Attachments: 2.0-6904.txt, 2.1-6904-v2.txt, 2.1-6904.txt > > > commitlog segments are archived when they are full, so the current active > segment will not be archived on restart (and its contents will not be > available for pitr). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[
https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152631#comment-14152631
]
Blake Eggleston commented on CASSANDRA-6246:
bq. Inconsistencies can be introduced by machines being down or network
partitioned for longer than we replay missed updates to it. Currently for
normal writes, hint is for 1 hour. If you bring in a machine after 1 hour, you
run a repair. But repair won't help here since it takes time to run the repair
and new LWTs will come and will see a different view of the data and won't
apply.
For serialized queries, new instances sent to a machine that's recovering from
a failure will be learn of missed instances during the preaccept phase, and
will have to catch up before they can execute the instance and respond to client
{quote}
"Assuming each instance is an average of ~170 bytes (uncompressed), sustained
1000 instances per second for 3 hours would keep ~1.8GB of data around."
Here instance includes the condition and update. Update could be quite big and
keeping it around could be problematic.
{quote}
Yeah... agree 100%. Keeping an extensive history of instances for failure
recovery is not a good idea. Anyway, it doesn't even solve the problem of
recovery since you'll start to get dangling pointers.
So let's forget about keeping a lot of history around.
For recovering from longer outages, here's my thinking:
To accurately determine dependencies for the preaccept phase, we'll need to
keep references to active instances around. Otherwise we can get dependency
graphs that are split, or have gaps. Active instances would be instances that
both been executed, and that either a quorum of instances have accepted as a
dependency for another instance, or that was a dependency of a committed
instance.
This should be all the historical info we need to keep around. We might want to
keep a little more so we can just use the prepare phase to recover from shorter
outages.
In cases where a node is joining, or has been down for a while, it seems that
if we immediately start including them in paxos messages (for record only, not
to act on), then send them the current dependency data described above for a
row/cell from a quorum of nodes and the current value for that row/cell, that
should be enough for the node to start participating in instances. This way we
can avoid a prepare phase that depends on persisting and transmitting a ton of
data.
wdyt? I haven't spent a lot of time thinking through all the edge cases, but I
think it has potential for making recovery practical.
> EPaxos
> --
>
> Key: CASSANDRA-6246
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6246
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Blake Eggleston
>Priority: Minor
>
> One reason we haven't optimized our Paxos implementation with Multi-paxos is
> that Multi-paxos requires leader election and hence, a period of
> unavailability when the leader dies.
> EPaxos is a Paxos variant that requires (1) less messages than multi-paxos,
> (2) is particularly useful across multiple datacenters, and (3) allows any
> node to act as coordinator:
> http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf
> However, there is substantial additional complexity involved if we choose to
> implement it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[ https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152622#comment-14152622 ] Matthew O'Riordan commented on CASSANDRA-8022: -- Yes, I can enter "commands" in, but they are simply echoed back to me, nothing happens. I've attached another console to the container that is running cqlsh, and run the `lsof` command: ``` lsof -a -p 614 -d0,1,2 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME python 614 root0u CHR 136,11 0t0 14 /dev/pts/11 python 614 root1w FIFO0,8 0t0 661702 pipe python 614 root2w FIFO0,8 0t0 661702 pipe ``` PS. Sorry, I am not familiar with JIRA markup, and the link below does not work for help on the formatting, how do you mark text as code? > cqlsh hangs indefinitely within a Docker container connecting to itself with > hostname > - > > Key: CASSANDRA-8022 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 > Project: Cassandra > Issue Type: Bug > Components: Tools > Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 > container. >Reporter: Matthew O'Riordan > Fix For: 2.1.0 > > > I am unable to use the `cqlsh` tool within a Docker container running > Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as > follows: > ``` > cqlsh --username cassandra --password whatever $(hostname) > ``` > When I run the `cqlsh` command after attaching to a running container (I use > LXC containerisation that allows attaching to a running container and running > a console), it simply hangs and never reports an error. With the `--debug` > flag on, I get the following with: > **cqlsh 4.1.1** > ``` > $ cqlsh --debug --username cassandra --password obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'> > Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'> > ``` > It then hangs in this state indefinitely, I have no errors from `cqlsh` and > no errors in the Cassandra log. > **cqlsh 5.0.1** > ``` > $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) > Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'> > ``` > It then also hangs in this state indefinitely, I have no errors from `cqlsh` > and no errors in the Cassandra log. > What's interesting, and quite confusing is that: > * I can telnet within the container as follows `telnet $(hostname) 9042` and > I get a socket. When trying to issue some commands, I see Protocol errors in > the Cassandra log thus verifying that the port is indeed open on the host > that resolves from $(hostname) > * If I `cqlsh` from another container or another host to the Cassandra > container it works just fine. > * I have tried disabling authentication altogether and using the > AllowAllAuthenticator, and I experience the same problem. > * `nodetool` works fine > In the mean time, I am forced to `cqlsh` from another container as a > workaround. Happy to try and do anything require to diagnose the cause of > this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152592#comment-14152592 ] sankalp kohli commented on CASSANDRA-6246: -- Inconsistencies can be introduced by machines being down or network partitioned for longer than we replay missed updates to it. Currently for normal writes, hint is for 1 hour. If you bring in a machine after 1 hour, you run a repair. But repair won't help here since it takes time to run the repair and new LWTs will come and will see a different view of the data and won't apply. "However, like I mentioned in my comment yesterday, I think we can work out a way to detect and correct this." +1 "Assuming each instance is an average of ~170 bytes (uncompressed), sustained 1000 instances per second for 3 hours would keep ~1.8GB of data around." Here instance includes the condition and update. Update could be quite big and keeping it around could be problematic. > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7949) LCS compaction low performance, many pending compactions, nodes are almost idle
[
https://issues.apache.org/jira/browse/CASSANDRA-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152569#comment-14152569
]
Nikolai Grigoriev commented on CASSANDRA-7949:
--
Upgraded to Cassandra 2.0.10 (via DSE 4.5.2) today. Switched my tables that
used STCS to LCS. Restarted. For last 8 hours I observe this on all nodes:
{code}
# nodetool compactionstats
pending tasks: 13808
compaction typekeyspace table completed
total unit progress
Compaction mykeyspacetable_1528230773591
1616185183262 bytes32.68%
Compaction mykeyspace table_2456361916088
4158821946280 bytes10.97%
Active compaction remaining time : 3h57m56s
{code}
In the beginning of these 8 hours the remaining time was about 4h08m. CPU
activity - almost nothing (between 2 and 3 cores), disk I/O - nearly zero. So
clearly it compacts in one thread per keyspace and almost does not progress.
> LCS compaction low performance, many pending compactions, nodes are almost
> idle
> ---
>
> Key: CASSANDRA-7949
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7949
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: DSE 4.5.1-1, Cassandra 2.0.8
>Reporter: Nikolai Grigoriev
> Attachments: iostats.txt, nodetool_compactionstats.txt,
> nodetool_tpstats.txt, pending compactions 2day.png, system.log.gz, vmstat.txt
>
>
> I've been evaluating new cluster of 15 nodes (32 core, 6x800Gb SSD disks +
> 2x600Gb SAS, 128Gb RAM, OEL 6.5) and I've built a simulator that creates the
> load similar to the load in our future product. Before running the simulator
> I had to pre-generate enough data. This was done using Java code and DataStax
> Java driver. To avoid going deep into details, two tables have been
> generated. Each table currently has about 55M rows and between few dozens and
> few thousands of columns in each row.
> This data generation process was generating massive amount of non-overlapping
> data. Thus, the activity was write-only and highly parallel. This is not the
> type of the traffic that the system will have ultimately to deal with, it
> will be mix of reads and updates to the existing data in the future. This is
> just to explain the choice of LCS, not mentioning the expensive SSD disk
> space.
> At some point while generating the data I have noticed that the compactions
> started to pile up. I knew that I was overloading the cluster but I still
> wanted the genration test to complete. I was expecting to give the cluster
> enough time to finish the pending compactions and get ready for real traffic.
> However, after the storm of write requests have been stopped I have noticed
> that the number of pending compactions remained constant (and even climbed up
> a little bit) on all nodes. After trying to tune some parameters (like
> setting the compaction bandwidth cap to 0) I have noticed a strange pattern:
> the nodes were compacting one of the CFs in a single stream using virtually
> no CPU and no disk I/O. This process was taking hours. After that it would be
> followed by a short burst of few dozens of compactions running in parallel
> (CPU at 2000%, some disk I/O - up to 10-20%) and then getting stuck again for
> many hours doing one compaction at time. So it looks like this:
> # nodetool compactionstats
> pending tasks: 3351
> compaction typekeyspace table completed
> total unit progress
>Compaction myks table_list1 66499295588
> 1910515889913 bytes 3.48%
> Active compaction remaining time :n/a
> # df -h
> ...
> /dev/sdb1.5T 637G 854G 43% /cassandra-data/disk1
> /dev/sdc1.5T 425G 1.1T 29% /cassandra-data/disk2
> /dev/sdd1.5T 429G 1.1T 29% /cassandra-data/disk3
> # find . -name **table_list1**Data** | grep -v snapshot | wc -l
> 1310
> Among these files I see:
> 1043 files of 161Mb (my sstable size is 160Mb)
> 9 large files - 3 between 1 and 2Gb, 3 of 5-8Gb, 55Gb, 70Gb and 370Gb
> 263 files of various sized - between few dozens of Kb and 160Mb
> I've been running the heavy load for about 1,5days and it's been close to 3
> days after that and the number of pending compactions does not go down.
> I have applied one of the not-so-obvious recommendations to disable
> multithreaded compactions and that seems to be helping a bit - I see some
> nodes started to have fewer pending compactions. About half of the cluster,
> in fact. But even there I see they are sitting idle most of the time lazily
> compacting in one stream with CPU at ~140% and occasionally doing the bursts
> of compa
[jira] [Commented] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152514#comment-14152514
]
Mikhail Stepura commented on CASSANDRA-8022:
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{ lsof -a -p -d0,1,2}} ?
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Fix For: 2.1.0
>
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
[
https://issues.apache.org/jira/browse/CASSANDRA-8022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152514#comment-14152514
]
Mikhail Stepura edited comment on CASSANDRA-8022 at 9/29/14 11:34 PM:
--
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{lsof -a -p -d0,1,2}} ?
was (Author: mishail):
Can you enter commands into that "hung" cqlsh?
Can you also check the output for {{ lsof -a -p -d0,1,2}} ?
> cqlsh hangs indefinitely within a Docker container connecting to itself with
> hostname
> -
>
> Key: CASSANDRA-8022
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8022
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04
> container.
>Reporter: Matthew O'Riordan
> Fix For: 2.1.0
>
>
> I am unable to use the `cqlsh` tool within a Docker container running
> Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as
> follows:
> ```
> cqlsh --username cassandra --password whatever $(hostname)
> ```
> When I run the `cqlsh` command after attaching to a running container (I use
> LXC containerisation that allows attaching to a running container and running
> a console), it simply hangs and never reports an error. With the `--debug`
> flag on, I get the following with:
> **cqlsh 4.1.1**
> ```
> $ cqlsh --debug --username cassandra --password obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cql-internal-only-1.4.1.zip/cql-1.4.1/cql/__init__.py'>
> Using thrift lib: '/usr/share/cassandra/lib/thrift-python-internal-only-0.9.1.zip/thrift/__init__.py'>
> ```
> It then hangs in this state indefinitely, I have no errors from `cqlsh` and
> no errors in the Cassandra log.
> **cqlsh 5.0.1**
> ```
> $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname)
> Using CQL driver: '/usr/share/cassandra/lib/cassandra-driver-internal-only-2.1.0.post.zip/cassandra-driver-2.1.0.post/cassandra/__init__.py'>
> ```
> It then also hangs in this state indefinitely, I have no errors from `cqlsh`
> and no errors in the Cassandra log.
> What's interesting, and quite confusing is that:
> * I can telnet within the container as follows `telnet $(hostname) 9042` and
> I get a socket. When trying to issue some commands, I see Protocol errors in
> the Cassandra log thus verifying that the port is indeed open on the host
> that resolves from $(hostname)
> * If I `cqlsh` from another container or another host to the Cassandra
> container it works just fine.
> * I have tried disabling authentication altogether and using the
> AllowAllAuthenticator, and I experience the same problem.
> * `nodetool` works fine
> In the mean time, I am forced to `cqlsh` from another container as a
> workaround. Happy to try and do anything require to diagnose the cause of
> this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152444#comment-14152444
]
Yuki Morishita commented on CASSANDRA-8020:
---
This is introduced in CASSANDRA-7024.
> nodetool repair on Cassandra 2.1.0 indexed tables returns java exception
> about creating snapshots
> -
>
> Key: CASSANDRA-8020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
> 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB
> RAM
>Reporter: Jeronimo A Barros
> Labels: newbie
> Fix For: 2.1.0
>
> Attachments: system.log.2014-09-29_1127
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
> exception about creating snapshots:
> Command line:
> {noformat}
> [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> [2014-09-29 11:25:24,945] Repair command #5 finished
> {noformat}
> Cassandra log:
> {noformat}
> ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 -
> Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
> (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.io.IOException: Failed during snapshot creation.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> [na:1.7.0_67]
> at
> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> Caused by: java.lang.RuntimeException: java.io.IOException: Failed during
> snapshot creation.
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_67]
> ... 1 common frames omitted
> Caused by: java.io.IOException: Failed during snapshot creation.
> at
> org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> ~[guava-16.0.jar:na]
> ... 3 common frames omitted
> {noformat}
> If the index is dropped, the repair returns no error:
> {noformat}
> cqlsh:test> drop INDEX user_pass_idx ;
> root@test:~# nodetool repair test user
> [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges
> for keyspace test (seq=true, full=true)
> .
> .
> [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] finished
> [2014-09-29 11:28:38,030] Repair command #6 finished
> {noformat}
> The test table:
> {noformat}
> CREATE TABLE test.user (
> login text PRIMARY KEY,
> password text
> )
> create INDEX user_pass_idx on test.user (password) ;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152442#comment-14152442
]
Yuki Morishita commented on CASSANDRA-8020:
---
Confirmed.
When snapshotting, replica node is throwing the following on indexed table:
{code}
ERROR [AntiEntropyStage:768] 2014-09-29 17:34:25,654 CassandraDaemon.java:166 -
Exception in thread Thread[AntiEntropyStage:768,5,main]
java.lang.ClassCastException: java.lang.Long cannot be cast to
java.nio.ByteBuffer
at org.apache.cassandra.db.marshal.BytesType.compare(BytesType.java:29)
~[main/:na]
at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:44)
~[main/:na]
at org.apache.cassandra.dht.LocalToken.compareTo(LocalToken.java:24)
~[main/:na]
at org.apache.cassandra.dht.Range.contains(Range.java:71) ~[main/:na]
at org.apache.cassandra.dht.Range.contains(Range.java:111) ~[main/:na]
at org.apache.cassandra.dht.Range.intersects(Range.java:142) ~[main/:na]
at org.apache.cassandra.dht.Range.intersects(Range.java:129) ~[main/:na]
at
org.apache.cassandra.dht.AbstractBounds.intersects(AbstractBounds.java:83)
~[main/:na]
at
org.apache.cassandra.repair.RepairMessageVerbHandler$1.apply(RepairMessageVerbHandler.java:83)
~[main/:na]
at
org.apache.cassandra.repair.RepairMessageVerbHandler$1.apply(RepairMessageVerbHandler.java:80)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.snapshotWithoutFlush(ColumnFamilyStore.java:2152)
~[main/:na]
at
org.apache.cassandra.db.ColumnFamilyStore.snapshot(ColumnFamilyStore.java:2215)
~[main/:na]
at
org.apache.cassandra.repair.RepairMessageVerbHandler.doVerb(RepairMessageVerbHandler.java:79)
~[main/:na]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
~[main/:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_51]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_51]
at java.lang.Thread.run(Thread.java:744) ~[na:1.7.0_51]
{code}
> nodetool repair on Cassandra 2.1.0 indexed tables returns java exception
> about creating snapshots
> -
>
> Key: CASSANDRA-8020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
> 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB
> RAM
>Reporter: Jeronimo A Barros
> Labels: newbie
> Fix For: 2.1.0
>
> Attachments: system.log.2014-09-29_1127
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
> exception about creating snapshots:
> Command line:
> {noformat}
> [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> [2014-09-29 11:25:24,945] Repair command #5 finished
> {noformat}
> Cassandra log:
> {noformat}
> ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 -
> Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
> (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.io.IOException: Failed during snapshot creation.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> [na:1.7.0_67]
> at
> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> Caused by: java.lang.RuntimeException: java.io.IOException: Failed during
> snapshot creation.
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.
[jira] [Assigned] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie reassigned CASSANDRA-8019:
--
Assignee: Joshua McKenzie
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
>Assignee: Joshua McKenzie
> Labels: windows
> Fix For: 2.1.1
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152383#comment-14152383 ] Blake Eggleston commented on CASSANDRA-6246: [~kohlisankalp] right, the incrementing ballot numbers per partition in the current implementation, and the quorum read basically synchronizes r/w for the partition being queried. But that synchronization creates a bottleneck, and the potential for live lock. Epaxos doesn't need to synchronize any of it's reads or writes. The preaccept, accept, and commit steps are basically building a directed graph of queries. The constraints those steps impose/satisfy allow other nodes to figure out the state of the graph on other machines in case of failure, provided it can talk to a quorum of nodes, and even if the machines with a newer view of the graph are down. At execution time, this graph is sorted to determine the execution order. Since the graph will always be the same, the order instances are executed will always be the same. So even though each machine will perform it's read and write in isolation, the other nodes are guaranteed to execute instances in the same order, and therefore, guaranteed to reach the same decision. Even though they aren't talking to each other at execution time. What can cause inconsistencies, since each node is executing instances in isolation, is users mixing serialized writes with unserialized writes. The quorum read/write in the current implementation mitigates this problem. However, like I mentioned in my comment yesterday, I think we can work out a way to detect and correct this. > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jeronimo A Barros updated CASSANDRA-8020:
-
Attachment: system.log.2014-09-29_1127
nodetool repair system.log
> nodetool repair on Cassandra 2.1.0 indexed tables returns java exception
> about creating snapshots
> -
>
> Key: CASSANDRA-8020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
> 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB
> RAM
>Reporter: Jeronimo A Barros
> Labels: newbie
> Fix For: 2.1.0
>
> Attachments: system.log.2014-09-29_1127
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
> exception about creating snapshots:
> Command line:
> {noformat}
> [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> [2014-09-29 11:25:24,945] Repair command #5 finished
> {noformat}
> Cassandra log:
> {noformat}
> ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 -
> Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
> (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.io.IOException: Failed during snapshot creation.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> [na:1.7.0_67]
> at
> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> Caused by: java.lang.RuntimeException: java.io.IOException: Failed during
> snapshot creation.
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_67]
> ... 1 common frames omitted
> Caused by: java.io.IOException: Failed during snapshot creation.
> at
> org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> ~[guava-16.0.jar:na]
> ... 3 common frames omitted
> {noformat}
> If the index is dropped, the repair returns no error:
> {noformat}
> cqlsh:test> drop INDEX user_pass_idx ;
> root@test:~# nodetool repair test user
> [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges
> for keyspace test (seq=true, full=true)
> .
> .
> [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] finished
> [2014-09-29 11:28:38,030] Repair command #6 finished
> {noformat}
> The test table:
> {noformat}
> CREATE TABLE test.user (
> login text PRIMARY KEY,
> password text
> )
> create INDEX user_pass_idx on test.user (password) ;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152357#comment-14152357
]
Jeronimo A Barros commented on CASSANDRA-8020:
--
Carl, no "Error occurred during snapshot phase". But I took another look (yes,
I should have done this before) and the beginning of the "nodetool repair"
points to the AntiEntropyStage class:
{noformat}
NFO [Thread-49681] 2014-09-29 11:25:22,787 StorageService.java:2595 - Starting
repair command #5, repairing 743 ranges for keyspace test (seq=true, full=true)
INFO [AntiEntropySessions:17] 2014-09-29 11:25:24,264 RepairSession.java:260 -
[repair #736daa80-47e4-11e4-ba0f-c7788dc924ec] new session: will sync
c1.test.net/192.168.33.248, /192.168.33.250, /192.168.33.252 on range
(-7990332010750800111,-7986163865225197304] for test.[user]
ERROR [AntiEntropyStage:1487] 2014-09-29 11:25:24,265 CassandraDaemon.java:166
- Exception in thread Thread[AntiEntropyStage:1487,5,main]
java.lang.ClassCastException: null
ERROR [RepairJobTask:3] 2014-09-29 11:25:24,266 RepairJob.java:127 - Error
occurred during snapshot phase
java.lang.RuntimeException: Could not create snapshot at /192.168.33.248
at
org.apache.cassandra.repair.SnapshotTask$SnapshotCallback.onFailure(SnapshotTask.java:77)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.net.ResponseVerbHandler.doVerb(ResponseVerbHandler.java:48)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:62)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
ERROR [AntiEntropySessions:17] 2014-09-29 11:25:24,266 RepairSession.java:303 -
[repair #736daa80-47e4-11e4-ba0f-c7788dc924ec] session completed with the
following error
java.io.IOException: Failed during snapshot creation.
at
org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128)
~[apache-cassandra-2.1.0.jar:2.1.0]
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
~[guava-16.0.jar:na]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
{noformat}
I'm attaching the full log of the error.
> nodetool repair on Cassandra 2.1.0 indexed tables returns java exception
> about creating snapshots
> -
>
> Key: CASSANDRA-8020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
> 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB
> RAM
>Reporter: Jeronimo A Barros
> Labels: newbie
> Fix For: 2.1.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
> exception about creating snapshots:
> Command line:
> {noformat}
> [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> [2014-09-29 11:25:24,945] Repair command #5 finished
> {noformat}
> Cassandra log:
> {noformat}
> ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 -
> Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
> (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.io.IOException: Failed during snapshot creation.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> [na:1.7.0_67]
> at
> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.u
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152336#comment-14152336 ] Blake Eggleston commented on CASSANDRA-6246: [~tjake] that'll solve the problem of having multiple mutations at a single timestamp, but might cause other problems when the calculated execution order puts an instance after an instance with a larger timestamp. Using arbitrary timestamps in uuid1s in this case might cause come collisions, but they wouldn't be on the same cells. In any case, collisions would be less likely than they are now. > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
[
https://issues.apache.org/jira/browse/CASSANDRA-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152320#comment-14152320
]
Carl Yeksigian commented on CASSANDRA-8020:
---
It looks like there was an error while trying to create the snapshot. Can you
look through the logs for "Error occurred during snapshot phase"? This will
help pin down the original cause of the failed repair.
> nodetool repair on Cassandra 2.1.0 indexed tables returns java exception
> about creating snapshots
> -
>
> Key: CASSANDRA-8020
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
> Project: Cassandra
> Issue Type: Bug
> Components: Core, Tools
> Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
> 3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB
> RAM
>Reporter: Jeronimo A Barros
> Labels: newbie
> Fix For: 2.1.0
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
> exception about creating snapshots:
> Command line:
> {noformat}
> [2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> [2014-09-29 11:25:24,945] Repair command #5 finished
> {noformat}
> Cassandra log:
> {noformat}
> ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 -
> Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
> (-7298689860784559350,-7297558156602685286] failed with error
> java.io.IOException: Failed during snapshot creation.
> java.util.concurrent.ExecutionException: java.lang.RuntimeException:
> java.io.IOException: Failed during snapshot creation.
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> [na:1.7.0_67]
> at
> org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
> Caused by: java.lang.RuntimeException: java.io.IOException: Failed during
> snapshot creation.
> at com.google.common.base.Throwables.propagate(Throwables.java:160)
> ~[guava-16.0.jar:na]
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
> [apache-cassandra-2.1.0.jar:2.1.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_67]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> [na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_67]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> ~[na:1.7.0_67]
> ... 1 common frames omitted
> Caused by: java.io.IOException: Failed during snapshot creation.
> at
> org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at
> org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
> ~[guava-16.0.jar:na]
> ... 3 common frames omitted
> {noformat}
> If the index is dropped, the repair returns no error:
> {noformat}
> cqlsh:test> drop INDEX user_pass_idx ;
> root@test:~# nodetool repair test user
> [2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges
> for keyspace test (seq=true, full=true)
> .
> .
> [2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec
> for range (-7298689860784559350,-7297558156602685286] finished
> [2014-09-29 11:28:38,030] Repair command #6 finished
> {noformat}
> The test table:
> {noformat}
> CREATE TABLE test.user (
> login text PRIMARY KEY,
> password text
> )
> create INDEX user_pass_idx on test.user (password) ;
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152316#comment-14152316 ] sankalp kohli commented on CASSANDRA-6246: -- Currently we do a read on quorum/local_quorum and based on that value decide if the condition matches at the co-ordinator. With you approach, the decisions will now be local and could be different on different replicas. If some replica some how lags behind due to various reasons, the condition on it will never be satisfied going forward. Coming back to my suggestion from previous comment, if all replicas respond back with all committed before this instance and things are the same, we can use the read value. Correct? > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8022) cqlsh hangs indefinitely within a Docker container connecting to itself with hostname
Matthew O'Riordan created CASSANDRA-8022: Summary: cqlsh hangs indefinitely within a Docker container connecting to itself with hostname Key: CASSANDRA-8022 URL: https://issues.apache.org/jira/browse/CASSANDRA-8022 Project: Cassandra Issue Type: Bug Components: Tools Environment: Ubuntu 14.04, running Docker, run inside a Ubuntu 14.04 container. Reporter: Matthew O'Riordan Fix For: 2.1.0 I am unable to use the `cqlsh` tool within a Docker container running Cassandra. Previously I would use the Java & Thrift based `cqlsh` tool as follows: ``` cqlsh --username cassandra --password whatever $(hostname) ``` When I run the `cqlsh` command after attaching to a running container (I use LXC containerisation that allows attaching to a running container and running a console), it simply hangs and never reports an error. With the `--debug` flag on, I get the following with: **cqlsh 4.1.1** ``` $ cqlsh --debug --username cassandra --password obfuscated $(hostname) Using CQL driver: Using thrift lib: ``` It then hangs in this state indefinitely, I have no errors from `cqlsh` and no errors in the Cassandra log. **cqlsh 5.0.1** ``` $ cqlsh --debug --username cassandra --passwor obfuscated $(hostname) Using CQL driver: ``` It then also hangs in this state indefinitely, I have no errors from `cqlsh` and no errors in the Cassandra log. What's interesting, and quite confusing is that: * I can telnet within the container as follows `telnet $(hostname) 9042` and I get a socket. When trying to issue some commands, I see Protocol errors in the Cassandra log thus verifying that the port is indeed open on the host that resolves from $(hostname) * If I `cqlsh` from another container or another host to the Cassandra container it works just fine. * I have tried disabling authentication altogether and using the AllowAllAuthenticator, and I experience the same problem. * `nodetool` works fine In the mean time, I am forced to `cqlsh` from another container as a workaround. Happy to try and do anything require to diagnose the cause of this problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8016) Auth tables should use higher consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152179#comment-14152179 ] Jonathan Ellis commented on CASSANDRA-8016: --- I think the reasoning was to maximize availability. Better to run with out of date permissions, than not run at all. > Auth tables should use higher consistency level > --- > > Key: CASSANDRA-8016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8016 > Project: Cassandra > Issue Type: Bug >Reporter: T Jake Luciani > Fix For: 2.0.11 > > > The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of > the superuser. > Since the Auth keyspace is created with RF=1 the default experience is fine. > However if you change to RF > 1 suddenly the select statements are open to > misses. > We should change reads/writes in Auth, PasswordAuthenticator, > CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM. > For reads we could optimize the code to start with CL.ONE and on a miss > increase to CL.QUORUM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6904) commitlog segments may not be archived after restart
[ https://issues.apache.org/jira/browse/CASSANDRA-6904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152144#comment-14152144 ] Charles Cao commented on CASSANDRA-6904: Is there anybody reviewing the patch now? > commitlog segments may not be archived after restart > > > Key: CASSANDRA-6904 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6904 > Project: Cassandra > Issue Type: Bug > Components: Core >Reporter: Jonathan Ellis >Assignee: Sam Tunnicliffe > Fix For: 2.0.11, 2.1.1 > > Attachments: 2.0-6904.txt, 2.1-6904-v2.txt, 2.1-6904.txt > > > commitlog segments are archived when they are full, so the current active > segment will not be archived on restart (and its contents will not be > available for pitr). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8021) Improve cqlsh autocomplete for alter keyspace
Philip Thompson created CASSANDRA-8021:
--
Summary: Improve cqlsh autocomplete for alter keyspace
Key: CASSANDRA-8021
URL: https://issues.apache.org/jira/browse/CASSANDRA-8021
Project: Cassandra
Issue Type: Improvement
Reporter: Philip Thompson
Assignee: Philip Thompson
Priority: Minor
Fix For: 2.0.11
Cqlsh autocomplete stops giving suggestions for the statement
{code}ALTER KEYSPACE k WITH REPLICATION { 'class' : 'SimpleStrategy',
'replication_factor' : 1'};{code} after the word "WITH".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8020) nodetool repair on Cassandra 2.1.0 indexed tables returns java exception about creating snapshots
Jeronimo A Barros created CASSANDRA-8020:
Summary: nodetool repair on Cassandra 2.1.0 indexed tables returns
java exception about creating snapshots
Key: CASSANDRA-8020
URL: https://issues.apache.org/jira/browse/CASSANDRA-8020
Project: Cassandra
Issue Type: Bug
Components: Core, Tools
Environment: Cassandra 2.1.0, Slackware 64bits 14.1, Linux Kernel
3.14.19, JDK build 1.7.0_67-b01, cluster with six nodes, Xeon E3-1230, 32GB RAM
Reporter: Jeronimo A Barros
Fix For: 2.1.0
Running a nodetool repair on Cassandra 2.1.0 indexed tables returns java
exception about creating snapshots:
Command line:
{noformat}
[2014-09-29 11:25:24,945] Repair session 73c0d390-47e4-11e4-ba0f-c7788dc924ec
for range (-7298689860784559350,-7297558156602685286] failed with error
java.io.IOException: Failed during snapshot creation.
[2014-09-29 11:25:24,945] Repair command #5 finished
{noformat}
Cassandra log:
{noformat}
ERROR [Thread-49681] 2014-09-29 11:25:24,945 StorageService.java:2689 - Repair
session 73c0d390-47e4-11e4-ba0f-c7788dc924ec for range
(-7298689860784559350,-7297558156602685286] failed with error
java.io.IOException: Failed during snapshot creation.
java.util.concurrent.ExecutionException: java.lang.RuntimeException:
java.io.IOException: Failed during snapshot creation.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
[na:1.7.0_67]
at java.util.concurrent.FutureTask.get(FutureTask.java:188)
[na:1.7.0_67]
at
org.apache.cassandra.service.StorageService$4.runMayThrow(StorageService.java:2680)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
[apache-cassandra-2.1.0.jar:2.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[na:1.7.0_67]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[na:1.7.0_67]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
Caused by: java.lang.RuntimeException: java.io.IOException: Failed during
snapshot creation.
at com.google.common.base.Throwables.propagate(Throwables.java:160)
~[guava-16.0.jar:na]
at
org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:32)
[apache-cassandra-2.1.0.jar:2.1.0]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
[na:1.7.0_67]
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
~[na:1.7.0_67]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
~[na:1.7.0_67]
... 1 common frames omitted
Caused by: java.io.IOException: Failed during snapshot creation.
at
org.apache.cassandra.repair.RepairSession.failedSnapshot(RepairSession.java:344)
~[apache-cassandra-2.1.0.jar:2.1.0]
at
org.apache.cassandra.repair.RepairJob$2.onFailure(RepairJob.java:128)
~[apache-cassandra-2.1.0.jar:2.1.0]
at com.google.common.util.concurrent.Futures$4.run(Futures.java:1172)
~[guava-16.0.jar:na]
... 3 common frames omitted
{noformat}
If the index is dropped, the repair returns no error:
{noformat}
cqlsh:test> drop INDEX user_pass_idx ;
root@test:~# nodetool repair test user
[2014-09-29 11:27:29,668] Starting repair command #6, repairing 743 ranges for
keyspace test (seq=true, full=true)
.
.
[2014-09-29 11:28:38,030] Repair session e6d40e10-47e4-11e4-ba0f-c7788dc924ec
for range (-7298689860784559350,-7297558156602685286] finished
[2014-09-29 11:28:38,030] Repair command #6 finished
{noformat}
The test table:
{noformat}
CREATE TABLE test.user (
login text PRIMARY KEY,
password text
)
create INDEX user_pass_idx on test.user (password) ;
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7734) Schema pushes (seemingly) randomly not happening
[
https://issues.apache.org/jira/browse/CASSANDRA-7734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14152041#comment-14152041
]
graham sanderson commented on CASSANDRA-7734:
-
Giving this a little nudge - I am happy to take a look, but I don't really
understand what the intention is with the original code (i.e. lifecycle of
{{IncomingTcpConnection}})
> Schema pushes (seemingly) randomly not happening
>
>
> Key: CASSANDRA-7734
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7734
> Project: Cassandra
> Issue Type: Bug
>Reporter: graham sanderson
>Assignee: Aleksey Yeschenko
>
> We have been seeing problems since upgrade to 2.0.9 from 2.0.5.
> Basically after a while, new schema changes (we periodically add tables)
> start propagating very slowly to some nodes and fast to others. It looks from
> the logs and trace that in this case the "push" of the schema never happens
> (note a node has decided not to push to another node, it doesn't seem to
> start again) from the originating node to some of the other nodes. In this
> case though, we do see the other node end up pulling the schema some time
> later when it notices its schema is out of date.
> Here is code from 2.0.9 MigrationManager.announce
> {code}
>for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
> {
> // only push schema to nodes with known and equal versions
> if (!endpoint.equals(FBUtilities.getBroadcastAddress()) &&
> MessagingService.instance().knowsVersion(endpoint) &&
> MessagingService.instance().getRawVersion(endpoint) ==
> MessagingService.current_version)
> pushSchemaMutation(endpoint, schema);
> }
> {code}
> and from 2.0.5
> {code}
> for (InetAddress endpoint : Gossiper.instance.getLiveMembers())
> {
> if (endpoint.equals(FBUtilities.getBroadcastAddress()))
> continue; // we've dealt with localhost already
> // don't send schema to the nodes with the versions older than
> current major
> if (MessagingService.instance().getVersion(endpoint) <
> MessagingService.current_version)
> continue;
> pushSchemaMutation(endpoint, schema);
> }
> {code}
> the old getVersion() call would return MessagingService.current_version if
> the version was unknown, so the push would occur in this case. I don't have
> logging to prove this, but have strong suspicion that the version may end up
> null in some cases (which would have allowed schema propagation in 2.0.5, but
> not by somewhere after that and <= 2.0.9)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8011) Fail on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-8011:
--
Reviewer: sankalp kohli
> Fail on large batch sizes
> --
>
> Key: CASSANDRA-8011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 8011-trunk-v2.txt, 8011-trunk.txt
>
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
> Just education alone is not going to stop some of the largest batch sizes
> from being used. Just like we have a tombstone fail threshold, I propose that
> we have a batch size fail threshold.
> Maybe 10x warn?
> {{batch_fail_threshold: 50k}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8011) Fail on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carl Yeksigian updated CASSANDRA-8011:
--
Attachment: 8011-trunk-v2.txt
Adding a v2 which address [~kohlisankalp]'s comments.
> Fail on large batch sizes
> --
>
> Key: CASSANDRA-8011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 8011-trunk-v2.txt, 8011-trunk.txt
>
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
> Just education alone is not going to stop some of the largest batch sizes
> from being used. Just like we have a tombstone fail threshold, I propose that
> we have a batch size fail threshold.
> Maybe 10x warn?
> {{batch_fail_threshold: 50k}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151987#comment-14151987
]
Joshua McKenzie edited comment on CASSANDRA-8019 at 9/29/14 6:16 PM:
-
Trunk isn't having any issues so this is probably related to the
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050. Also -
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go
so far as dtesting to reproduce.
edit: I should mention - a cursory inspection of the changes in here look like
the try w/resources idiom should have closed the ScannerList references as
expected. [~benedict]: any initial thoughts, other than those that led to
CASSANDRA-7705?
was (Author: joshuamckenzie):
Trunk isn't having any issues so this is probably related to the
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050. Also -
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go
so far as dtesting to reproduce.
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
> Labels: windows
> Fix For: 2.1.1
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
[
https://issues.apache.org/jira/browse/CASSANDRA-8019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151987#comment-14151987
]
Joshua McKenzie commented on CASSANDRA-8019:
Trunk isn't having any issues so this is probably related to the
FILE_SHARE_DELETE flag problems we addressed with CASSANDRA-4050. Also -
simple unit tests are failing on Windows w/this in 2.1 branch so no need to go
so far as dtesting to reproduce.
> Windows Unit tests and Dtests erroring due to sstable deleting task error
> -
>
> Key: CASSANDRA-8019
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
> Project: Cassandra
> Issue Type: Bug
> Environment: Windows 7
>Reporter: Philip Thompson
> Labels: windows
> Fix For: 2.1.1
>
>
> Currently a large number of dtests and unit tests are erroring on windows
> with the following error in the node log:
> {code}
> ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383
> SSTableDeletingTask.java:89 - Unable to delete
> c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
> (it will be removed on server restart; we'll also retry after GC)\n
> {code}
> git bisect points to the following commit:
> {code}
> 0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
> commit 0e831007760bffced8687f51b99525b650d7e193
> Author: Benedict Elliott Smith
> Date: Fri Sep 19 18:17:19 2014 +0100
> Fix resource leak in event of corrupt sstable
> patch by benedict; review by yukim for CASSANDRA-7932
> :100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
> f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
> :04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
> 3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
> :04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
> de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
> {code}
> You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Issue Comment Deleted] (CASSANDRA-8008) "Timed out waiting for timer thread" on large stress command
[
https://issues.apache.org/jira/browse/CASSANDRA-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-8008:
---
Comment: was deleted
(was: Locally on single node of 2.1.0)
> "Timed out waiting for timer thread" on large stress command
>
>
> Key: CASSANDRA-8008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Shawn Kumar
> Attachments: file.log, node1-2.log, node1.log, node2-2.log,
> node2.log, perftest.log
>
>
> I've been using cstar_perf to test a performance scenario and was able to
> reproduce this error on a two node cluster with stock 2.1.0 while carrying
> out large stress writes (50M keys):
> {noformat}
> java.lang.RuntimeException: Timed out waiting for a timer thread - seems one
> got stuck
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
> at
> org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
> at
> org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It looks like a similar error to that found in CASSANDRA-6943. I've also
> attached the test log and thread dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8008) "Timed out waiting for timer thread" on large stress command
[
https://issues.apache.org/jira/browse/CASSANDRA-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-8008:
---
Attachment: file.log
Locally on single node of 2.1.0
> "Timed out waiting for timer thread" on large stress command
>
>
> Key: CASSANDRA-8008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Shawn Kumar
> Attachments: file.log, node1-2.log, node1.log, node2-2.log,
> node2.log, perftest.log
>
>
> I've been using cstar_perf to test a performance scenario and was able to
> reproduce this error on a two node cluster with stock 2.1.0 while carrying
> out large stress writes (50M keys):
> {noformat}
> java.lang.RuntimeException: Timed out waiting for a timer thread - seems one
> got stuck
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
> at
> org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
> at
> org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It looks like a similar error to that found in CASSANDRA-6943. I've also
> attached the test log and thread dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8008) "Timed out waiting for timer thread" on large stress command
[
https://issues.apache.org/jira/browse/CASSANDRA-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151959#comment-14151959
]
Shawn Kumar commented on CASSANDRA-8008:
Was able to reproduce locally on a single node running stock 2.1.0 as well,
attached an additional thread dump.
> "Timed out waiting for timer thread" on large stress command
>
>
> Key: CASSANDRA-8008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Shawn Kumar
> Attachments: node1-2.log, node1.log, node2-2.log, node2.log,
> perftest.log
>
>
> I've been using cstar_perf to test a performance scenario and was able to
> reproduce this error on a two node cluster with stock 2.1.0 while carrying
> out large stress writes (50M keys):
> {noformat}
> java.lang.RuntimeException: Timed out waiting for a timer thread - seems one
> got stuck
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
> at
> org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
> at
> org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It looks like a similar error to that found in CASSANDRA-6943. I've also
> attached the test log and thread dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-8019) Windows Unit tests and Dtests erroring due to sstable deleting task error
Philip Thompson created CASSANDRA-8019:
--
Summary: Windows Unit tests and Dtests erroring due to sstable
deleting task error
Key: CASSANDRA-8019
URL: https://issues.apache.org/jira/browse/CASSANDRA-8019
Project: Cassandra
Issue Type: Bug
Environment: Windows 7
Reporter: Philip Thompson
Fix For: 2.1.1
Currently a large number of dtests and unit tests are erroring on windows with
the following error in the node log:
{code}
ERROR [NonPeriodicTasks:1] 2014-09-29 11:05:04,383 SSTableDeletingTask.java:89
- Unable to delete
c:\\users\\username\\appdata\\local\\temp\\dtest-vr6qgw\\test\\node1\\data\\system\\local-7ad54392bcdd35a684174e047860b377\\system-local-ka-4-Data.db
(it will be removed on server restart; we'll also retry after GC)\n
{code}
git bisect points to the following commit:
{code}
0e831007760bffced8687f51b99525b650d7e193 is the first bad commit
commit 0e831007760bffced8687f51b99525b650d7e193
Author: Benedict Elliott Smith
Date: Fri Sep 19 18:17:19 2014 +0100
Fix resource leak in event of corrupt sstable
patch by benedict; review by yukim for CASSANDRA-7932
:100644 100644 d3ee7d99179dce03307503a8093eb47bd0161681
f55e5d27c1c53db3485154cd16201fc5419f32df M CHANGES.txt
:04 04 194f4c0569b6be9cc9e129c441433c5c14de7249
3c62b53b2b2bd4b212ab6005eab38f8a8e228923 M src
:04 04 64f49266e328b9fdacc516c52ef1921fe42e994f
de2ca38232bee6d2a6a5e068ed9ee0fbbc5aaebe M test
{code}
You can reproduce this by running simple_bootstrap_test.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMIT KUMAR updated CASSANDRA-7838: -- Attachment: (was: 0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch) > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7523) add date and time types
[ https://issues.apache.org/jira/browse/CASSANDRA-7523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-7523: --- Labels: docs (was: ) > add date and time types > --- > > Key: CASSANDRA-7523 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7523 > Project: Cassandra > Issue Type: New Feature > Components: API >Reporter: Jonathan Ellis >Assignee: Joshua McKenzie >Priority: Minor > Labels: docs > Fix For: 2.1.1, 3.0 > > > http://www.postgresql.org/docs/9.1/static/datatype-datetime.html > (we already have timestamp; interval is out of scope for now, and see > CASSANDRA-6350 for discussion on timestamp-with-time-zone. but date/time > should be pretty easy to add.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMIT KUMAR updated CASSANDRA-7838: -- Attachment: 0010-Minor-log-change-happy-path.patch 0009-Bug-fix-swap-check-was-incorrect-fixed-logging-state.patch 0008-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch 0007-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch 0006-added-missing-winnt-native.patch 0005-CASSANDRA-7838-log-warning-for-networked-drives.patch new patches with corrected log statement and swap check fix. > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > Attachments: > 0005-CASSANDRA-7838-log-warning-for-networked-drives.patch, > 0006-added-missing-winnt-native.patch, > 0007-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, > 0008-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch, > 0009-Bug-fix-swap-check-was-incorrect-fixed-logging-state.patch, > 0010-Minor-log-change-happy-path.patch > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8018) Cassandra seems to insert twice in custom PerColumnSecondaryIndex
Pavel Chlupacek created CASSANDRA-8018:
--
Summary: Cassandra seems to insert twice in custom
PerColumnSecondaryIndex
Key: CASSANDRA-8018
URL: https://issues.apache.org/jira/browse/CASSANDRA-8018
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Pavel Chlupacek
Fix For: 2.1.0
When inserting data into Cassandra 2.1.0 into table with custom secondary
index, the Cell is inserted twice, if inserting new entry into row with same
rowId, but different cluster index columns.
CREATE KEYSPACE fulltext WITH replication = {'class': 'SimpleStrategy',
'replication_factor' : 1};
CREATE TABLE fulltext.test ( id uuid, name text, name2 text, json varchar,
lucene text, primary key ( id , name));
s"CREATE CUSTOM INDEX lucene_idx on fulltext.test(lucene) using
'com.spinoco.fulltext.cassandra.TestIndex'; "
// this causes only one insert
insertInto("fulltext","test")
.value("id", id1.uuid)
.value("name", "goosh1")
.value("json", TestContent.message1.asJson)
// this causes 2 inserts to be done
insertInto("fulltext","test")
.value("id", id1.uuid)
.value("name", "goosh2")
.value("json", TestContent.message2.asJson)
/// stacktraces for inserts (always same, for 1st and 2nd insert)
and then
at
org.apache.cassandra.db.index.SecondaryIndexManager$StandardUpdater.insert(SecondaryIndexManager.java:707)
at
org.apache.cassandra.db.AtomicBTreeColumns$ColumnUpdater.apply(AtomicBTreeColumns.java:344)
at
org.apache.cassandra.db.AtomicBTreeColumns$ColumnUpdater.apply(AtomicBTreeColumns.java:319)
at
org.apache.cassandra.utils.btree.NodeBuilder.addNewKey(NodeBuilder.java:323)
at
org.apache.cassandra.utils.btree.NodeBuilder.update(NodeBuilder.java:191)
at org.apache.cassandra.utils.btree.Builder.update(Builder.java:74)
at org.apache.cassandra.utils.btree.BTree.update(BTree.java:186)
at
org.apache.cassandra.db.AtomicBTreeColumns.addAllWithSizeDelta(AtomicBTreeColumns.java:189)
at org.apache.cassandra.db.Memtable.put(Memtable.java:194)
at
org.apache.cassandra.db.ColumnFamilyStore.apply(ColumnFamilyStore.java:1142)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:394)
at org.apache.cassandra.db.Keyspace.apply(Keyspace.java:351)
at org.apache.cassandra.db.Mutation.apply(Mutation.java:214)
at
org.apache.cassandra.service.StorageProxy$7.runMayThrow(StorageProxy.java:970)
at
org.apache.cassandra.service.StorageProxy$LocalMutationRunnable.run(StorageProxy.java:2080)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at
org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:163)
at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:103)
at java.lang.Thread.run(Thread.java:744)
Note that cell, rowkey and Group in public abstract void insert(ByteBuffer
rowKey, Cell col, OpOrder.Group opGroup); are having for both successive calls
same identity
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMIT KUMAR updated CASSANDRA-7838: -- Attachment: (was: 0002-added-missing-winnt-native.patch) > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8014) NPE in Message.java line 324
[
https://issues.apache.org/jira/browse/CASSANDRA-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151810#comment-14151810
]
Brandon Williams commented on CASSANDRA-8014:
-
Look like something in disuptor, [~xedin]. Harmless though.
> NPE in Message.java line 324
>
>
> Key: CASSANDRA-8014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.0.9
>Reporter: Peter Haggerty
>Assignee: Pavel Yaskevich
> Attachments: NPE_Message.java_line-324.txt
>
>
> We received this when a server was rebooting and attempted to shut Cassandra
> down while it was still quite busy. While it's normal for us to have a
> handful of the RejectedExecution exceptions on a sudden shutdown like this
> these NPEs in Message.java are new.
> The attached file include the logs from "StorageServiceShutdownHook" to the
> "Logging initialized" after the server restarts and Cassandra comes back up.
> {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line
> 324) Unexpected throwable while invoking!
> java.lang.NullPointerException
> at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
> at
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
> at
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
> at
> org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
> at
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMIT KUMAR updated CASSANDRA-7838: -- Attachment: (was: 0001-CASSANDRA-7838-log-warning-for-networked-drives.patch) > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] AMIT KUMAR updated CASSANDRA-7838: -- Attachment: (was: 0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch) > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151831#comment-14151831 ] AMIT KUMAR commented on CASSANDRA-7838: --- Sorry for the swap disable snafu -I made the fix and the changed the log statements Attached are the patches from the trunk. -I am a little hesitant in saying OK in the happy path scenario, because we have not checked everything that could lead to bad performance of Cassandra due to sysctl and hardware issues and saying OK might give a false sense of security. Let me know if you see any other issues -thanks for your help. > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > Attachments: > 0001-CASSANDRA-7838-log-warning-for-networked-drives.patch, > 0002-added-missing-winnt-native.patch, > 0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, > 0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8012) cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
[
https://issues.apache.org/jira/browse/CASSANDRA-8012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8012:
---
Labels: cqlsh (was: )
> cqlsh "DESCRIBE KEYSPACES;" returns empty after upgrade
> ---
>
> Key: CASSANDRA-8012
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8012
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment: cassandra 2.1.0
>Reporter: Shawn Zhou
> Labels: cqlsh
>
> after upgrade from 2.0.7 to 2.1.0
> run cqlsh "DESCRIBE KEYSPACES;" returns empty result;
> query individual table does return data;
> See below:
> {noformat}
> [root@dc1-stg-cassandra-08 cassandra]# cqlsh
> dc1-stg-cassandra-08.dc01.revsci.net -k as_user_segment
> Connected to Stage Cluster at dc1-stg-cassandra-08.dc01.revsci.net:9042.
> [cqlsh 5.0.1 | Cassandra 2.1.0 | CQL spec 3.2.0 | Native protocol v3]
> Use HELP for help.
> cqlsh:as_user_segment> DESCRIBE KEYSPACES;
>
> cqlsh:as_user_segment> select * from user_segments_blob where id =
> '8e6090087fc1a7591a99dc4cb744ac43';
> id | segments
> --+
> 8e6090087fc1a7591a99dc4cb744ac43 |
> 0x9416b015911d3b0e211aee227216ab1cdf0f4204
> (1 rows)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-8014) NPE in Message.java line 324
[
https://issues.apache.org/jira/browse/CASSANDRA-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brandon Williams reassigned CASSANDRA-8014:
---
Assignee: Pavel Yaskevich
> NPE in Message.java line 324
>
>
> Key: CASSANDRA-8014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.0.9
>Reporter: Peter Haggerty
>Assignee: Pavel Yaskevich
> Attachments: NPE_Message.java_line-324.txt
>
>
> We received this when a server was rebooting and attempted to shut Cassandra
> down while it was still quite busy. While it's normal for us to have a
> handful of the RejectedExecution exceptions on a sudden shutdown like this
> these NPEs in Message.java are new.
> The attached file include the logs from "StorageServiceShutdownHook" to the
> "Logging initialized" after the server restarts and Cassandra comes back up.
> {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line
> 324) Unexpected throwable while invoking!
> java.lang.NullPointerException
> at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
> at
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
> at
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
> at
> org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
> at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
> at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
> at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
> at
> com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
> at
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
> at
> com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
> at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8014) NPE in Message.java line 324
[
https://issues.apache.org/jira/browse/CASSANDRA-8014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-8014:
---
Description:
We received this when a server was rebooting and attempted to shut Cassandra
down while it was still quite busy. While it's normal for us to have a handful
of the RejectedExecution exceptions on a sudden shutdown like this these NPEs
in Message.java are new.
The attached file include the logs from "StorageServiceShutdownHook" to the
"Logging initialized" after the server restarts and Cassandra comes back up.
{code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324)
Unexpected throwable while invoking!
java.lang.NullPointerException
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
at
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
at
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
at
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
at
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
at
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
{code}
was:
We received this when a server was rebooting and attempted to shut Cassandra
down while it was still quite busy. While it's normal for us to have a handful
of the RejectedExecution exceptions on a sudden shutdown like this these NPEs
in Message.java are new.
The attached file include the logs from "StorageServiceShutdownHook" to the
"Logging initialized" after the server restarts and Cassandra comes back up.
ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324)
Unexpected throwable while invoking!
java.lang.NullPointerException
at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
at
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
at
com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167)
at
org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156)
at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55)
at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
at com.thinkaurelius.thrift.Message.invoke(Message.java:314)
at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90)
at
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638)
at
com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632)
at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
> NPE in Message.java line 324
>
>
> Key: CASSANDRA-8014
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8014
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.0.9
>Reporter: Peter Haggerty
> Attachments: NPE_Message.java_line-324.txt
>
>
> We received this when a server was rebooting and attempted to shut Cassandra
> down while it was still quite busy. While it's normal for us to have a
> handful of the RejectedExecution exceptions on a sudden shutdown like this
> these NPEs in Message.java are new.
> The attached file include the logs from "StorageServiceShutdownHook" to the
> "Logging initialized" after the server restarts and Cassandra comes back up.
> {code}ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line
> 324) Unexpected throwable while invoking!
> java.lang.NullPointerException
> at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83)
> at
> com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84)
> at
> com.thi
[jira] [Commented] (CASSANDRA-8007) sstableloader throws exceptions when used with '-cph'
[
https://issues.apache.org/jira/browse/CASSANDRA-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151798#comment-14151798
]
Joshua McKenzie commented on CASSANDRA-8007:
+1
> sstableloader throws exceptions when used with '-cph'
> -
>
> Key: CASSANDRA-8007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8007
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Minor
> Labels: streaming
> Fix For: 2.1.1
>
> Attachments: 8007-2.1.txt
>
>
> When I use {{sstableloader}} with {{-cph}}(connections per host) option
> greater than 1, I get the following exceptions.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:637)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {code}
> also,
> {code}
> ERROR 14:33:52 [Stream #218f2470-458a-11e4-a929-cb31cb113424] Streaming error
> occurred
> java.lang.AssertionError: Reference counter -1 for
> /home/yuki/Keyspace1/Standard1-cb5e6f30458811e49349511b628b066f/Keyspace1-Standard1-ka-6-Data.db
> at
> org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1597)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:68)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:522)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:404)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:295)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {code}
> Looks like there are conflict in grabbing SSTables to stream.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-6898) describing a table with compression should expand the compression options
[
https://issues.apache.org/jira/browse/CASSANDRA-6898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar resolved CASSANDRA-6898.
Resolution: Fixed
> describing a table with compression should expand the compression options
> -
>
> Key: CASSANDRA-6898
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6898
> Project: Cassandra
> Issue Type: Bug
> Components: API
>Reporter: Brandon Williams
>Priority: Minor
> Fix For: 2.0.11
>
>
> {noformat}
> cqlsh:foo> CREATE TABLE baz ( foo text, bar text, primary KEY (foo)) WITH
> compression = {};
> cqlsh:foo> DESCRIBE TABLE baz;
> CREATE TABLE baz (
> foo text,
> bar text,
> PRIMARY KEY (foo)
> ) WITH
> bloom_filter_fp_chance=0.01 AND
> caching='KEYS_ONLY' AND
> comment='' AND
> dclocal_read_repair_chance=0.00 AND
> gc_grace_seconds=864000 AND
> index_interval=128 AND
> read_repair_chance=0.10 AND
> replicate_on_write='true' AND
> populate_io_cache_on_flush='false' AND
> default_time_to_live=0 AND
> speculative_retry='99.0PERCENTILE' AND
> memtable_flush_period_in_ms=0 AND
> compaction={'class': 'SizeTieredCompactionStrategy'} AND
> compression={};
> cqlsh:foo>
> {noformat}
> From this, you can't tell that LZ4 compression is enabled, even though it is.
> It would be more friendly to expand the option to show the defaults.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7983) nodetool repair triggers OOM
[
https://issues.apache.org/jira/browse/CASSANDRA-7983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jimmy Mårdell updated CASSANDRA-7983:
-
Attachment: 7983-v1.patch
> nodetool repair triggers OOM
>
>
> Key: CASSANDRA-7983
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7983
> Project: Cassandra
> Issue Type: Bug
> Components: Tools
> Environment:
> {noformat}
> INFO [main] 2014-09-16 14:23:14,621 DseDaemon.java (line 368) DSE version:
> 4.5.0
> INFO [main] 2014-09-16 14:23:14,622 DseDaemon.java (line 369) Hadoop
> version: 1.0.4.13
> INFO [main] 2014-09-16 14:23:14,627 DseDaemon.java (line 370) Hive version:
> 0.12.0.3
> INFO [main] 2014-09-16 14:23:14,628 DseDaemon.java (line 371) Pig version:
> 0.10.1
> INFO [main] 2014-09-16 14:23:14,629 DseDaemon.java (line 372) Solr version:
> 4.6.0.2.4
> INFO [main] 2014-09-16 14:23:14,630 DseDaemon.java (line 373) Sqoop version:
> 1.4.4.14.1
> INFO [main] 2014-09-16 14:23:14,630 DseDaemon.java (line 374) Mahout
> version: 0.8
> INFO [main] 2014-09-16 14:23:14,631 DseDaemon.java (line 375) Appender
> version: 3.0.2
> INFO [main] 2014-09-16 14:23:14,632 DseDaemon.java (line 376) Spark version:
> 0.9.1
> INFO [main] 2014-09-16 14:23:14,632 DseDaemon.java (line 377) Shark version:
> 0.9.1.1
> INFO [main] 2014-09-16 14:23:20,270 CassandraDaemon.java (line 160) JVM
> vendor/version: Java HotSpot(TM) 64-Bit Server VM/1.7.0_51
> INFO [main] 2014-09-16 14:23:20,270 CassandraDaemon.java (line 188) Heap
> size: 6316621824/6316621824
> {noformat}
>Reporter: Jose Martinez Poblete
>Assignee: Yuki Morishita
> Fix For: 2.0.11
>
> Attachments: 7983-v1.patch, gc.log.0, nbcqa-chc-a01_systemlog.tar.Z,
> nbcqa-chc-a03_systemlog.tar.Z, system.log
>
>
> Customer has a 3 node cluster with 500Mb data on each node
> {noformat}
> [cassandra@nbcqa-chc-a02 ~]$ nodetool status
> Note: Ownership information does not include topology; for complete
> information, specify a keyspace
> Datacenter: CH2
> ===
> Status=Up/Down
> |/ State=Normal/Leaving/Joining/Moving
> -- AddressLoad Tokens Owns Host ID
> Rack
> UN 162.150.4.234 255.26 MB 256 33.2%
> 4ad1b6a8-8759-4920-b54a-f059126900df RAC1
> UN 162.150.4.235 318.37 MB 256 32.6%
> 3eb0ec58-4b81-442e-bee5-4c91da447f38 RAC1
> UN 162.150.4.167 243.7 MB 256 34.2%
> 5b2c1900-bf03-41c1-bb4e-82df1655b8d8 RAC1
> [cassandra@nbcqa-chc-a02 ~]$
> {noformat}
> After we run repair command, system runs into OOM after some 45 minutes
> Nothing else is running
> {noformat}
> [cassandra@nbcqa-chc-a02 ~]$ date
> Fri Sep 19 15:55:33 UTC 2014
> [cassandra@nbcqa-chc-a02 ~]$ nodetool repair -st -9220354588320251877 -et
> -9220354588320251873
> Sep 19, 2014 4:06:08 PM ClientCommunicatorAdmin Checker-run
> WARNING: Failed to check the connection: java.net.SocketTimeoutException:
> Read timed out
> {noformat}
> Herer is when we run OOM
> {noformat}
> ERROR [ReadStage:28914] 2014-09-19 16:34:50,381 CassandraDaemon.java (line
> 199) Exception in thread Thread[ReadStage:28914,5,main]
> java.lang.OutOfMemoryError: Java heap space
> at
> org.apache.cassandra.io.util.RandomAccessReader.(RandomAccessReader.java:69)
> at
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.(CompressedRandomAccessReader.java:76)
> at
> org.apache.cassandra.io.compress.CompressedRandomAccessReader.open(CompressedRandomAccessReader.java:43)
> at
> org.apache.cassandra.io.util.CompressedPoolingSegmentedFile.createReader(CompressedPoolingSegmentedFile.java:48)
> at
> org.apache.cassandra.io.util.PoolingSegmentedFile.getSegment(PoolingSegmentedFile.java:39)
> at
> org.apache.cassandra.io.sstable.SSTableReader.getFileDataInput(SSTableReader.java:1195)
> at
> org.apache.cassandra.db.columniterator.SimpleSliceReader.(SimpleSliceReader.java:57)
> at
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.createReader(SSTableSliceIterator.java:65)
> at
> org.apache.cassandra.db.columniterator.SSTableSliceIterator.(SSTableSliceIterator.java:42)
> at
> org.apache.cassandra.db.filter.SliceQueryFilter.getSSTableColumnIterator(SliceQueryFilter.java:167)
> at
> org.apache.cassandra.db.filter.QueryFilter.getSSTableColumnIterator(QueryFilter.java:62)
> at
> org.apache.cassandra.db.CollationController.collectAllData(CollationController.java:250)
> at
> org.apache.cassandra.db.CollationController.getTopLevelColumns(CollationController.java:53)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getTopLevelColumns(ColumnFamilyStore.java:1547)
> at
> org.apache.cassandra.db.ColumnFamilyStore.getColumnFamily(ColumnFamilyStore.java:1376)
>
[jira] [Updated] (CASSANDRA-8007) sstableloader throws exceptions when used with '-cph'
[
https://issues.apache.org/jira/browse/CASSANDRA-8007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuki Morishita updated CASSANDRA-8007:
--
Attachment: 8007-2.1.txt
Looks like sstableloader is over releasing reference when '-cph' > 1.
{{StreamCoordinator#sliceSSTableDetails}} needs to remove content from given
SSTablesStreamingSection when splitting as in
{{StreamSession#addTransferFile}}, so that the same SSTable does not get
over-released after adding to StreamPlan
(https://github.com/apache/cassandra/blob/cassandra-2.1/src/java/org/apache/cassandra/io/sstable/SSTableLoader.java#L195).
> sstableloader throws exceptions when used with '-cph'
> -
>
> Key: CASSANDRA-8007
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8007
> Project: Cassandra
> Issue Type: Bug
>Reporter: Yuki Morishita
>Assignee: Yuki Morishita
>Priority: Minor
> Labels: streaming
> Fix For: 2.1.1
>
> Attachments: 8007-2.1.txt
>
>
> When I use {{sstableloader}} with {{-cph}}(connections per host) option
> greater than 1, I get the following exceptions.
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.cassandra.io.sstable.SSTableReader$6.run(SSTableReader.java:637)
> ~[main/:na]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> ~[na:1.7.0_51]
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> ~[na:1.7.0_51]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {code}
> also,
> {code}
> ERROR 14:33:52 [Stream #218f2470-458a-11e4-a929-cb31cb113424] Streaming error
> occurred
> java.lang.AssertionError: Reference counter -1 for
> /home/yuki/Keyspace1/Standard1-cb5e6f30458811e49349511b628b066f/Keyspace1-Standard1-ka-6-Data.db
> at
> org.apache.cassandra.io.sstable.SSTableReader.releaseReference(SSTableReader.java:1597)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamTransferTask.complete(StreamTransferTask.java:68)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.received(StreamSession.java:522)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.StreamSession.messageReceived(StreamSession.java:404)
> ~[main/:na]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:295)
> ~[main/:na]
> at java.lang.Thread.run(Thread.java:744) [na:1.7.0_51]
> {code}
> Looks like there are conflict in grabbing SSTables to stream.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-7766) Secondary index not working after a while
[
https://issues.apache.org/jira/browse/CASSANDRA-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar resolved CASSANDRA-7766.
Resolution: Cannot Reproduce
> Secondary index not working after a while
> -
>
> Key: CASSANDRA-7766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
>Reporter: Fabrice Larcher
> Attachments: result-failure.txt, result-success.txt
>
>
> Since 2.1.0-rc2, it appears that the secondary indexes are not always
> working. Immediately after the INSERT of a row, the index seems to be there.
> But after a while (I do not know when or why), SELECT statements based on any
> secondary index do not return the corresponding row(s) anymore. I noticed
> that a restart of C* may have an impact (the data inserted before the restart
> may be seen through the index, even if it was not returned before the
> restart).
> Here is a use-case example (in order to clarify my request) :
> {code}
> CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
> CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
> INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
> SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
> {code}
> The last SELECT statement may or may not return a row depending on the
> instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with
> clusters of one and two nodes. Since it depends on the instant of the
> request, I am not able to deliver any way to reproduce that systematically
> (It appears to be linked with some scheduled job inside C*).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7766) Secondary index not working after a while
[
https://issues.apache.org/jira/browse/CASSANDRA-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151761#comment-14151761
]
Shawn Kumar commented on CASSANDRA-7766:
Was unable to reproduce this over a period of a few days. Please feel free to
reopen the ticket if you come across any further information that could help us
reproduce this.
> Secondary index not working after a while
> -
>
> Key: CASSANDRA-7766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
>Reporter: Fabrice Larcher
> Attachments: result-failure.txt, result-success.txt
>
>
> Since 2.1.0-rc2, it appears that the secondary indexes are not always
> working. Immediately after the INSERT of a row, the index seems to be there.
> But after a while (I do not know when or why), SELECT statements based on any
> secondary index do not return the corresponding row(s) anymore. I noticed
> that a restart of C* may have an impact (the data inserted before the restart
> may be seen through the index, even if it was not returned before the
> restart).
> Here is a use-case example (in order to clarify my request) :
> {code}
> CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
> CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
> INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
> SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
> {code}
> The last SELECT statement may or may not return a row depending on the
> instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with
> clusters of one and two nodes. Since it depends on the instant of the
> request, I am not able to deliver any way to reproduce that systematically
> (It appears to be linked with some scheduled job inside C*).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-7766) Secondary index not working after a while
[
https://issues.apache.org/jira/browse/CASSANDRA-7766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-7766:
---
Description:
Since 2.1.0-rc2, it appears that the secondary indexes are not always working.
Immediately after the INSERT of a row, the index seems to be there. But after a
while (I do not know when or why), SELECT statements based on any secondary
index do not return the corresponding row(s) anymore. I noticed that a restart
of C* may have an impact (the data inserted before the restart may be seen
through the index, even if it was not returned before the restart).
Here is a use-case example (in order to clarify my request) :
{code}
CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
{code}
The last SELECT statement may or may not return a row depending on the instant
of the request. I experienced that with 2.1.0-rc5 through CQLSH with clusters
of one and two nodes. Since it depends on the instant of the request, I am not
able to deliver any way to reproduce that systematically (It appears to be
linked with some scheduled job inside C*).
was:
cSince 2.1.0-rc2, it appears that the secondary indexes are not always working.
Immediately after the INSERT of a row, the index seems to be there. But after a
while (I do not know when or why), SELECT statements based on any secondary
index do not return the corresponding row(s) anymore. I noticed that a restart
of C* may have an impact (the data inserted before the restart may be seen
through the index, even if it was not returned before the restart).
Here is a use-case example (in order to clarify my request) :
{code}
CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
{code}
The last SELECT statement may or may not return a row depending on the instant
of the request. I experienced that with 2.1.0-rc5 through CQLSH with clusters
of one and two nodes. Since it depends on the instant of the request, I am not
able to deliver any way to reproduce that systematically (It appears to be
linked with some scheduled job inside C*).
> Secondary index not working after a while
> -
>
> Key: CASSANDRA-7766
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7766
> Project: Cassandra
> Issue Type: Bug
> Environment: C* 2.1.0-rc5 with small clusters (one or two nodes)
>Reporter: Fabrice Larcher
> Attachments: result-failure.txt, result-success.txt
>
>
> Since 2.1.0-rc2, it appears that the secondary indexes are not always
> working. Immediately after the INSERT of a row, the index seems to be there.
> But after a while (I do not know when or why), SELECT statements based on any
> secondary index do not return the corresponding row(s) anymore. I noticed
> that a restart of C* may have an impact (the data inserted before the restart
> may be seen through the index, even if it was not returned before the
> restart).
> Here is a use-case example (in order to clarify my request) :
> {code}
> CREATE TABLE IF NOT EXISTS ks.cf ( k int PRIMARY KEY, ind ascii, value text);
> CREATE INDEX IF NOT EXISTS ks_cf_index ON ks.cf(ind);
> INSERT INTO ks.cf (k, ind, value) VALUES (1, 'toto', 'Hello');
> SELECT * FROM ks.cf WHERE ind = 'toto'; // Returns no result after a while
> {code}
> The last SELECT statement may or may not return a row depending on the
> instant of the request. I experienced that with 2.1.0-rc5 through CQLSH with
> clusters of one and two nodes. Since it depends on the instant of the
> request, I am not able to deliver any way to reproduce that systematically
> (It appears to be linked with some scheduled job inside C*).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[2/8] git commit: Ignore fat clients when checking for endpoint collision
Ignore fat clients when checking for endpoint collision
Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f
Branch: refs/heads/cassandra-2.1
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams
Committed: Mon Sep 29 09:46:02 2014 -0500
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
* CrcCheckChance should adjust based on live CFMetadata not
sstable metadata (CASSANDRA-7978)
* token() should only accept columns in the partitioning
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
MessagingService.instance().listen(FBUtilities.getLocalAddress());
Gossiper.instance.doShadowRound();
EndpointState epState =
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null && !Gossiper.instance.isDeadState(epState))
+if (epState != null && !Gossiper.instance.isDeadState(epState) &&
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
{
throw new RuntimeException(String.format("A node with address %s
already exists, cancelling join. " +
"Use
cassandra.replace_address if you want to replace this node.",
[6/8] git commit: Ignore fat clients when checking for endpoint collision
Ignore fat clients when checking for endpoint collision
Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ece6f23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ece6f23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ece6f23
Branch: refs/heads/trunk
Commit: 3ece6f2399fa15c97d889c5d43b4a7457825e8e1
Parents: 5f18658
Author: Brandon Williams
Authored: Mon Sep 29 09:52:09 2014 -0500
Committer: Brandon Williams
Committed: Mon Sep 29 09:52:09 2014 -0500
--
CHANGES.txt | 1 +
.../apache/cassandra/service/StorageService.java| 16 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fca7ccb..354cb5d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.1
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
* Make sstablerepairedset take a list of files (CASSANDRA-7995)
* (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972)
* (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index a005c44..d2cb1ab 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -453,12 +453,26 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
MessagingService.instance().listen(FBUtilities.getLocalAddress());
Gossiper.instance.doShadowRound();
EndpointState epState =
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null && !Gossiper.instance.isDeadState(epState))
+if (epState != null && !Gossiper.instance.isDeadState(epState) &&
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
{
throw new RuntimeException(String.format("A node with address %s
already exists, cancelling join. " +
"Use
cassandra.replace_address if you want to replace this node.",
FBUtilities.getBroadcastAddress()));
}
+if (RangeStreamer.useStrictConsistency)
+{
+for (Map.Entry entry :
Gossiper.instance.getEndpointStates())
+{
+
+if
(entry.getValue().getApplicationState(ApplicationState.STATUS) == null)
+continue;
+String[] pieces =
entry.getValue().getApplicationState(ApplicationState.STATUS).value.split(VersionedValue.DELIMITER_STR,
-1);
+assert (pieces.length > 0);
+String state = pieces[0];
+if (state.equals(VersionedValue.STATUS_BOOTSTRAPPING) ||
state.equals(VersionedValue.STATUS_LEAVING) ||
state.equals(VersionedValue.STATUS_MOVING))
+throw new UnsupportedOperationException("Other
bootstrapping/leaving/moving nodes detected, cannot bootstrap while
cassandra.consistent.rangemovement is true");
+}
+}
Gossiper.instance.resetEndpointStateMap();
}
[3/8] git commit: Ignore fat clients when checking for endpoint collision
Ignore fat clients when checking for endpoint collision
Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f
Branch: refs/heads/trunk
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams
Committed: Mon Sep 29 09:46:02 2014 -0500
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
* CrcCheckChance should adjust based on live CFMetadata not
sstable metadata (CASSANDRA-7978)
* token() should only accept columns in the partitioning
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
MessagingService.instance().listen(FBUtilities.getLocalAddress());
Gossiper.instance.doShadowRound();
EndpointState epState =
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null && !Gossiper.instance.isDeadState(epState))
+if (epState != null && !Gossiper.instance.isDeadState(epState) &&
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
{
throw new RuntimeException(String.format("A node with address %s
already exists, cancelling join. " +
"Use
cassandra.replace_address if you want to replace this node.",
[1/8] git commit: Ignore fat clients when checking for endpoint collision
Repository: cassandra
Updated Branches:
refs/heads/cassandra-2.0 3db38d7ed -> 6b8b8e0f9
refs/heads/cassandra-2.1 ad60b7812 -> 3ece6f239
refs/heads/trunk 04f0d412b -> 9391fc03d
Ignore fat clients when checking for endpoint collision
Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/6b8b8e0f
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/6b8b8e0f
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/6b8b8e0f
Branch: refs/heads/cassandra-2.0
Commit: 6b8b8e0f924b53b9f99854f88ff9ba84073cb295
Parents: 3db38d7
Author: Brandon Williams
Authored: Mon Sep 29 09:46:02 2014 -0500
Committer: Brandon Williams
Committed: Mon Sep 29 09:46:02 2014 -0500
--
CHANGES.txt | 1 +
src/java/org/apache/cassandra/service/StorageService.java | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index 40e2f2c..dd5f7dd 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.0.11:
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
* CrcCheckChance should adjust based on live CFMetadata not
sstable metadata (CASSANDRA-7978)
* token() should only accept columns in the partitioning
http://git-wip-us.apache.org/repos/asf/cassandra/blob/6b8b8e0f/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index f693a0b..11eb91d 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -444,7 +444,7 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
MessagingService.instance().listen(FBUtilities.getLocalAddress());
Gossiper.instance.doShadowRound();
EndpointState epState =
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null && !Gossiper.instance.isDeadState(epState))
+if (epState != null && !Gossiper.instance.isDeadState(epState) &&
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
{
throw new RuntimeException(String.format("A node with address %s
already exists, cancelling join. " +
"Use
cassandra.replace_address if you want to replace this node.",
[4/8] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f186581 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f186581 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f186581 Branch: refs/heads/cassandra-2.1 Commit: 5f18658170b66714e46f82b8151c5fcab233d742 Parents: ad60b78 6b8b8e0 Author: Brandon Williams Authored: Mon Sep 29 09:46:47 2014 -0500 Committer: Brandon Williams Committed: Mon Sep 29 09:46:47 2014 -0500 -- --
[7/8] git commit: Ignore fat clients when checking for endpoint collision
Ignore fat clients when checking for endpoint collision
Patch by brandonwilliams, reviewed by tjake for CASSANDRA-7939
Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo
Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/3ece6f23
Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/3ece6f23
Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/3ece6f23
Branch: refs/heads/cassandra-2.1
Commit: 3ece6f2399fa15c97d889c5d43b4a7457825e8e1
Parents: 5f18658
Author: Brandon Williams
Authored: Mon Sep 29 09:52:09 2014 -0500
Committer: Brandon Williams
Committed: Mon Sep 29 09:52:09 2014 -0500
--
CHANGES.txt | 1 +
.../apache/cassandra/service/StorageService.java| 16 +++-
2 files changed, 16 insertions(+), 1 deletion(-)
--
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/CHANGES.txt
--
diff --git a/CHANGES.txt b/CHANGES.txt
index fca7ccb..354cb5d 100644
--- a/CHANGES.txt
+++ b/CHANGES.txt
@@ -1,4 +1,5 @@
2.1.1
+ * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939)
* Make sstablerepairedset take a list of files (CASSANDRA-7995)
* (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972)
* (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891)
http://git-wip-us.apache.org/repos/asf/cassandra/blob/3ece6f23/src/java/org/apache/cassandra/service/StorageService.java
--
diff --git a/src/java/org/apache/cassandra/service/StorageService.java
b/src/java/org/apache/cassandra/service/StorageService.java
index a005c44..d2cb1ab 100644
--- a/src/java/org/apache/cassandra/service/StorageService.java
+++ b/src/java/org/apache/cassandra/service/StorageService.java
@@ -453,12 +453,26 @@ public class StorageService extends
NotificationBroadcasterSupport implements IE
MessagingService.instance().listen(FBUtilities.getLocalAddress());
Gossiper.instance.doShadowRound();
EndpointState epState =
Gossiper.instance.getEndpointStateForEndpoint(FBUtilities.getBroadcastAddress());
-if (epState != null && !Gossiper.instance.isDeadState(epState))
+if (epState != null && !Gossiper.instance.isDeadState(epState) &&
!Gossiper.instance.isFatClient(FBUtilities.getBroadcastAddress()))
{
throw new RuntimeException(String.format("A node with address %s
already exists, cancelling join. " +
"Use
cassandra.replace_address if you want to replace this node.",
FBUtilities.getBroadcastAddress()));
}
+if (RangeStreamer.useStrictConsistency)
+{
+for (Map.Entry entry :
Gossiper.instance.getEndpointStates())
+{
+
+if
(entry.getValue().getApplicationState(ApplicationState.STATUS) == null)
+continue;
+String[] pieces =
entry.getValue().getApplicationState(ApplicationState.STATUS).value.split(VersionedValue.DELIMITER_STR,
-1);
+assert (pieces.length > 0);
+String state = pieces[0];
+if (state.equals(VersionedValue.STATUS_BOOTSTRAPPING) ||
state.equals(VersionedValue.STATUS_LEAVING) ||
state.equals(VersionedValue.STATUS_MOVING))
+throw new UnsupportedOperationException("Other
bootstrapping/leaving/moving nodes detected, cannot bootstrap while
cassandra.consistent.rangemovement is true");
+}
+}
Gossiper.instance.resetEndpointStateMap();
}
[5/8] git commit: Merge branch 'cassandra-2.0' into cassandra-2.1
Merge branch 'cassandra-2.0' into cassandra-2.1 Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/5f186581 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/5f186581 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/5f186581 Branch: refs/heads/trunk Commit: 5f18658170b66714e46f82b8151c5fcab233d742 Parents: ad60b78 6b8b8e0 Author: Brandon Williams Authored: Mon Sep 29 09:46:47 2014 -0500 Committer: Brandon Williams Committed: Mon Sep 29 09:46:47 2014 -0500 -- --
[8/8] git commit: Merge branch 'cassandra-2.1' into trunk
Merge branch 'cassandra-2.1' into trunk Project: http://git-wip-us.apache.org/repos/asf/cassandra/repo Commit: http://git-wip-us.apache.org/repos/asf/cassandra/commit/9391fc03 Tree: http://git-wip-us.apache.org/repos/asf/cassandra/tree/9391fc03 Diff: http://git-wip-us.apache.org/repos/asf/cassandra/diff/9391fc03 Branch: refs/heads/trunk Commit: 9391fc03d479a71d95386375f1a3037eb72d1898 Parents: 04f0d41 3ece6f2 Author: Brandon Williams Authored: Mon Sep 29 09:52:49 2014 -0500 Committer: Brandon Williams Committed: Mon Sep 29 09:52:49 2014 -0500 -- CHANGES.txt | 1 + .../apache/cassandra/service/StorageService.java| 16 +++- 2 files changed, 16 insertions(+), 1 deletion(-) -- http://git-wip-us.apache.org/repos/asf/cassandra/blob/9391fc03/CHANGES.txt -- diff --cc CHANGES.txt index b9ffacc,354cb5d..bbfc5cb --- a/CHANGES.txt +++ b/CHANGES.txt @@@ -1,32 -1,5 +1,33 @@@ +3.0 + * Remove cassandra-cli (CASSANDRA-7920) + * Optimize java source-based UDF invocation (CASSANDRA-7924) + * Accept dollar quoted strings in CQL (CASSANDRA-7769) + * Make assassinate a first class command (CASSANDRA-7935) + * Support IN clause on any clustering column (CASSANDRA-4762) + * Improve compaction logging (CASSANDRA-7818) + * Remove YamlFileNetworkTopologySnitch (CASSANDRA-7917) + * Support Java source code for user-defined functions (CASSANDRA-7562) + * Require arg types to disambiguate UDF drops (CASSANDRA-7812) + * Do anticompaction in groups (CASSANDRA-6851) + * Verify that UDF class methods are static (CASSANDRA-7781) + * Support pure user-defined functions (CASSANDRA-7395, 7740) + * Permit configurable timestamps with cassandra-stress (CASSANDRA-7416) + * Move sstable RandomAccessReader to nio2, which allows using the + FILE_SHARE_DELETE flag on Windows (CASSANDRA-4050) + * Remove CQL2 (CASSANDRA-5918) + * Add Thrift get_multi_slice call (CASSANDRA-6757) + * Optimize fetching multiple cells by name (CASSANDRA-6933) + * Allow compilation in java 8 (CASSANDRA-7028) + * Make incremental repair default (CASSANDRA-7250) + * Enable code coverage thru JaCoCo (CASSANDRA-7226) + * Switch external naming of 'column families' to 'tables' (CASSANDRA-4369) + * Shorten SSTable path (CASSANDRA-6962) + * Use unsafe mutations for most unit tests (CASSANDRA-6969) + * Fix race condition during calculation of pending ranges (CASSANDRA-7390) + + 2.1.1 + * Ignore fat clients when checking for endpoint collision (CASSANDRA-7939) * Make sstablerepairedset take a list of files (CASSANDRA-7995) * (cqlsh) Tab completeion for indexes on map keys (CASSANDRA-7972) * (cqlsh) Fix UDT field selection in select clause (CASSANDRA-7891) http://git-wip-us.apache.org/repos/asf/cassandra/blob/9391fc03/src/java/org/apache/cassandra/service/StorageService.java --
[jira] [Commented] (CASSANDRA-7838) Warn user when disks are network/ebs mounted
[ https://issues.apache.org/jira/browse/CASSANDRA-7838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151711#comment-14151711 ] T Jake Luciani commented on CASSANDRA-7838: --- Your isSwapDisabled check is backwards. Also, the log message warning is missing some : separators If all the checks pass we should log that everything looks OK. > Warn user when disks are network/ebs mounted > > > Key: CASSANDRA-7838 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7838 > Project: Cassandra > Issue Type: Improvement >Reporter: T Jake Luciani >Priority: Minor > Labels: bootcamp, lhf > Fix For: 3.0 > > Attachments: > 0001-CASSANDRA-7838-log-warning-for-networked-drives.patch, > 0002-added-missing-winnt-native.patch, > 0003-CASSANDRA-7838-WIP-adding-a-few-other-checks.patch, > 0004-CASSANDRA-7838-Removed-network-check-and-read-latenc.patch > > > The Sigar project let's you probe os/cpu/filesystems across the major > platforms. > https://github.com/hyperic/sigar > It would be nice on start-up to use this to warn users if they are running > with settings that will make them sad, like Network drive or EBS on Ec2. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Deleted] (CASSANDRA-8017) er()
[ https://issues.apache.org/jira/browse/CASSANDRA-8017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict deleted CASSANDRA-8017: > er() > > > Key: CASSANDRA-8017 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8017 > Project: Cassandra > Issue Type: Bug >Reporter: Benedict > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8017) er()
Benedict created CASSANDRA-8017: --- Summary: er() Key: CASSANDRA-8017 URL: https://issues.apache.org/jira/browse/CASSANDRA-8017 Project: Cassandra Issue Type: Bug Reporter: Benedict -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-8011) Fail on large batch sizes
[
https://issues.apache.org/jira/browse/CASSANDRA-8011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151118#comment-14151118
]
Carl Yeksigian edited comment on CASSANDRA-8011 at 9/29/14 1:55 PM:
Added the option which fails on very large batches.
{noformat}
batch_size_fail_threshold_in_kb: 50
{noformat}
was (Author: carlyeks):
Added the option which fails on very large batches.
{noformat}
batch_size_file_threshold_in_kb: 50
{noformat}
> Fail on large batch sizes
> --
>
> Key: CASSANDRA-8011
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8011
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Patrick McFadin
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 3.0
>
> Attachments: 8011-trunk.txt
>
>
> Related to https://issues.apache.org/jira/browse/CASSANDRA-6487
> Just education alone is not going to stop some of the largest batch sizes
> from being used. Just like we have a tombstone fail threshold, I propose that
> we have a batch size fail threshold.
> Maybe 10x warn?
> {{batch_fail_threshold: 50k}}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8008) "Timed out waiting for timer thread" on large stress command
[
https://issues.apache.org/jira/browse/CASSANDRA-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-8008:
---
Attachment: perftest.log
> "Timed out waiting for timer thread" on large stress command
>
>
> Key: CASSANDRA-8008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Shawn Kumar
> Attachments: node1-2.log, node1.log, node2-2.log, node2.log,
> perftest.log
>
>
> I've been using cstar_perf to test a performance scenario and was able to
> reproduce this error on a two node cluster with stock 2.1.0 while carrying
> out large stress writes (50M keys):
> {noformat}
> java.lang.RuntimeException: Timed out waiting for a timer thread - seems one
> got stuck
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
> at
> org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
> at
> org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It looks like a similar error to that found in CASSANDRA-6943. I've also
> attached the test log and thread dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8008) "Timed out waiting for timer thread" on large stress command
[
https://issues.apache.org/jira/browse/CASSANDRA-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Kumar updated CASSANDRA-8008:
---
Attachment: (was: perftest.log)
> "Timed out waiting for timer thread" on large stress command
>
>
> Key: CASSANDRA-8008
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8008
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: Shawn Kumar
> Attachments: node1-2.log, node1.log, node2-2.log, node2.log,
> perftest.log
>
>
> I've been using cstar_perf to test a performance scenario and was able to
> reproduce this error on a two node cluster with stock 2.1.0 while carrying
> out large stress writes (50M keys):
> {noformat}
> java.lang.RuntimeException: Timed out waiting for a timer thread - seems one
> got stuck
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:83)
> at org.apache.cassandra.stress.util.Timing.snap(Timing.java:118)
> at
> org.apache.cassandra.stress.StressMetrics.update(StressMetrics.java:156)
> at
> org.apache.cassandra.stress.StressMetrics.access$300(StressMetrics.java:42)
> at
> org.apache.cassandra.stress.StressMetrics$2.run(StressMetrics.java:104)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> It looks like a similar error to that found in CASSANDRA-6943. I've also
> attached the test log and thread dumps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-6246) EPaxos
[ https://issues.apache.org/jira/browse/CASSANDRA-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151693#comment-14151693 ] T Jake Luciani commented on CASSANDRA-6246: --- For write timestamps take a look at CASSANDRA-7919 we need to change this to support better LWW semantics and RAMP > EPaxos > -- > > Key: CASSANDRA-6246 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6246 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Jonathan Ellis >Assignee: Blake Eggleston >Priority: Minor > > One reason we haven't optimized our Paxos implementation with Multi-paxos is > that Multi-paxos requires leader election and hence, a period of > unavailability when the leader dies. > EPaxos is a Paxos variant that requires (1) less messages than multi-paxos, > (2) is particularly useful across multiple datacenters, and (3) allows any > node to act as coordinator: > http://sigops.org/sosp/sosp13/papers/p358-moraru.pdf > However, there is substantial additional complexity involved if we choose to > implement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-8016) Auth tables should use higher consistency level
[ https://issues.apache.org/jira/browse/CASSANDRA-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] T Jake Luciani updated CASSANDRA-8016: -- Description: The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of the superuser. Since the Auth keyspace is created with RF=1 the default experience is fine. However if you change to RF > 1 suddenly the select statements are open to misses. We should change reads/writes in Auth, PasswordAuthenticator, CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM. For reads we could optimize the code to start with CL.ONE and on a miss increase to CL.QUORUM was: The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of the superuser. Since the Auth keyspace is created with RF=1 the default experience is fine. However if you change to RF > 1 suddenly the select statements are open to misses. We should change reads/writes in Auth, PasswordAuthenticator, CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM. For reads if could optimize it to start with CL.ONE and on a miss increase to CL.QUORUM > Auth tables should use higher consistency level > --- > > Key: CASSANDRA-8016 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8016 > Project: Cassandra > Issue Type: Bug >Reporter: T Jake Luciani > Fix For: 2.0.11 > > > The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of > the superuser. > Since the Auth keyspace is created with RF=1 the default experience is fine. > However if you change to RF > 1 suddenly the select statements are open to > misses. > We should change reads/writes in Auth, PasswordAuthenticator, > CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM. > For reads we could optimize the code to start with CL.ONE and on a miss > increase to CL.QUORUM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8016) Auth tables should use higher consistency level
T Jake Luciani created CASSANDRA-8016: - Summary: Auth tables should use higher consistency level Key: CASSANDRA-8016 URL: https://issues.apache.org/jira/browse/CASSANDRA-8016 Project: Cassandra Issue Type: Bug Reporter: T Jake Luciani Fix For: 2.0.11 The Auth code in Cassandra uses CL.ONE or CL.LOCAL_ONE except in the case of the superuser. Since the Auth keyspace is created with RF=1 the default experience is fine. However if you change to RF > 1 suddenly the select statements are open to misses. We should change reads/writes in Auth, PasswordAuthenticator, CassandraAuthorizer to always use LOCAL_QUORUM/QUORUM. For reads if could optimize it to start with CL.ONE and on a miss increase to CL.QUORUM -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7969) Properly track min/max timestamps and maxLocalDeletionTimes for range and row tombstones
[ https://issues.apache.org/jira/browse/CASSANDRA-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151671#comment-14151671 ] Marcus Eriksson commented on CASSANDRA-7969: bq. the CQLtest should use the CQLTester class It will, in 2.1 where we have it (should maybe be backported to 2.0 as well?) > Properly track min/max timestamps and maxLocalDeletionTimes for range and row > tombstones > > > Key: CASSANDRA-7969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7969 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 2.0.11 > > Attachments: > 0001-track-min-max-timestamps-and-maxLocalDeletionTime-co.patch, > 0001-track-min-max-timestamps-and-maxLocalDeletionTime-v2.patch > > > First problem is that when we have only row or range tombstones in an sstable > we dont update the maxLocalDeletionTime for the sstable > Second problem is that if we have a range tombstone in an sstable, > minTimestamp will always be Long.MIN_VALUE for flushed sstables due to how we > set the default values for the variables -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7969) Properly track min/max timestamps and maxLocalDeletionTimes for range and row tombstones
[ https://issues.apache.org/jira/browse/CASSANDRA-7969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151667#comment-14151667 ] T Jake Luciani commented on CASSANDRA-7969: --- +1 nit: the CQLtest should use the CQLTester class > Properly track min/max timestamps and maxLocalDeletionTimes for range and row > tombstones > > > Key: CASSANDRA-7969 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7969 > Project: Cassandra > Issue Type: Bug >Reporter: Marcus Eriksson >Assignee: Marcus Eriksson > Fix For: 2.0.11 > > Attachments: > 0001-track-min-max-timestamps-and-maxLocalDeletionTime-co.patch, > 0001-track-min-max-timestamps-and-maxLocalDeletionTime-v2.patch > > > First problem is that when we have only row or range tombstones in an sstable > we dont update the maxLocalDeletionTime for the sstable > Second problem is that if we have a range tombstone in an sstable, > minTimestamp will always be Long.MIN_VALUE for flushed sstables due to how we > set the default values for the variables -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8015) nodetool exception for users with read only permissions on jmx authentication
Jose Martinez Poblete created CASSANDRA-8015:
Summary: nodetool exception for users with read only permissions
on jmx authentication
Key: CASSANDRA-8015
URL: https://issues.apache.org/jira/browse/CASSANDRA-8015
Project: Cassandra
Issue Type: Bug
Components: Core
Environment: Cassandra 2.0.8.39
Reporter: Jose Martinez Poblete
nodetool will throw exception for a read only user when JMX authentication is
enabled.
{noformat}
[automaton@i-0212b8098 ~]$ nodetool -u jose -pw JoseManuel status
Exception in thread "main" java.lang.SecurityException: Access denied! Invalid
access level for requested MBeanServer operation.
at
com.sun.jmx.remote.security.MBeanServerFileAccessController.checkAccess(MBeanServerFileAccessController.java:344)
at
com.sun.jmx.remote.security.MBeanServerFileAccessController.checkWrite(MBeanServerFileAccessController.java:240)
at
com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:466)
at
javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1487)
at
javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
at
javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
at java.security.AccessController.doPrivileged(Native Method)
at
javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
at
javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:848)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
at sun.rmi.transport.Transport$1.run(Transport.java:177)
at sun.rmi.transport.Transport$1.run(Transport.java:174)
at java.security.AccessController.doPrivileged(Native Method)
at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
at
sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
at
sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:275)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:252)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1029)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:292)
at com.sun.proxy.$Proxy0.effectiveOwnership(Unknown Source)
at
org.apache.cassandra.tools.NodeProbe.effectiveOwnership(NodeProbe.java:335)
at
org.apache.cassandra.tools.NodeCmd$ClusterStatus.print(NodeCmd.java:480)
at
org.apache.cassandra.tools.NodeCmd.printClusterStatus(NodeCmd.java:590)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:1263)
[automaton@i-0212b8098 ~]$ dse -v
4.5.1
[automaton@i-0212b8098 ~]$ cqlsh -u jose -p JoseManuel
Connected to Spark at localhost:9160.
[cqlsh 4.1.1 | Cassandra 2.0.8.39 | CQL spec 3.1.1 | Thrift protocol 19.39.0]
Use HELP for help.
cqlsh> exit;
[automaton@i-0212b8098 ~]$
{noformat}
Nodetool runs fine for cassandra user:
{noformat}
[automaton@i-0212b8098 ~]$ nodetool -u cassandra -pw cassandra status
Note: Ownership information does not include topology; for complete
information, specify a keyspace
Datacenter: Cassandra
=
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- AddressLoad Owns Host ID
TokenRack
UN 10.240.11.164 771.93 KB 100.0% ae672795-bd73-4f53-a371-1a35c8df28a1
-9223372036854775808 rack1
[automaton@i-0212b8098 ~]$
{noformat}
JMX authentication is enabled as described [here |
https://support.datastax.com/entries/43692547-Step-by-step-instructions-for-securing-JMX-authentication-for-nodetool-utility-OpsCenter-and-JConsol]
[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151608#comment-14151608
]
Marcus Olsson commented on CASSANDRA-7953:
--
Could an alternative be to change the onDiskAtomComparator to only check for
equal ranges, instead of inclusive ranges?
> RangeTombstones not merging during compaction
> -
>
> Key: CASSANDRA-7953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1
>Reporter: Marcus Olsson
>Priority: Minor
> Labels: compaction, deletes, tombstone
> Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch,
> CASSANDRA-7953.patch
>
>
> When performing a compaction on two sstables that contain the same
> RangeTombstone with different timestamps, the tombstones are not merged in
> the new sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
> key text,
> column text,
> data text,
> PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the
> sstable only contains tombstones during compaction it seems that the sstable
> either gets removed or isn't created (but that could probably be a separate
> JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inserts
> are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the
> compacted sstable. This can be repeated, resulting in more and more
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-8005) Server-side DESCRIBE
[
https://issues.apache.org/jira/browse/CASSANDRA-8005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151559#comment-14151559
]
Sylvain Lebresne commented on CASSANDRA-8005:
-
bq. Why would the drivers need to parse the string?
What I mean is that the drivers (at least the JAVA one, but I'd argue that any
good driver should do the same) exposes the schema in a programatic way (in
[KeyspaceMetadata|http://www.datastax.com/drivers/java/2.0/com/datastax/driver/core/KeyspaceMetadata.html],
[TableMetadata|http://www.datastax.com/drivers/java/2.0/com/datastax/driver/core/TableMetadata.html],
...) which is useful and not something we'd want to remove. It follows that
the driver will read the schema tables anyway (or, in your proposal of
replacing the read of the schema tables by a string, it would have to parse
that string). And since the drivers have the schema this way, re-generating the
string representation of it is pretty trivial (and the java driver does it).
So I argue that sending a string of the whole schema is somewhat useless for
drivers (but making schema table much more easily consumable is definitively
useful).
> Server-side DESCRIBE
>
>
> Key: CASSANDRA-8005
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8005
> Project: Cassandra
> Issue Type: New Feature
> Components: API
>Reporter: Tyler Hobbs
>Priority: Minor
> Labels: cql3
> Fix For: 3.0
>
>
> The various {{DESCRIBE}} commands are currently implemented by cqlsh, and
> nearly identical implementations exist in many drivers. There are several
> motivations for making {{DESCRIBE}} part of the CQL language:
> * Eliminate the (fairly complex) duplicate implementations across drivers and
> cqlsh
> * Get closer to allowing drivers to not have to fetch the schema tables.
> (Minor changes to prepared statements are also needed.)
> * Have instantaneous support for new schema features in cqlsh. (You
> currently have to update the bundled python driver.)
> * Support writing out schemas where it makes sense. One good example of this
> is backups. You need to restore the schema before restoring data in the case
> of total loss, so it makes sense to write out the schema alongside snapshots.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7859) Extend freezing to collections
[
https://issues.apache.org/jira/browse/CASSANDRA-7859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151547#comment-14151547
]
Sylvain Lebresne commented on CASSANDRA-7859:
-
bq. By default, indexes on frozen collections will index the entire collection.
What bother me about that is the inconstency with non-frozen collections and I
do feel that this inconsistency will be unintuitive. So I would prefer leaving
the default be indexing by values, and add some new keyword for indexing entire
collections. Something like {{CREATE INDEX ON foo(fullCollection(myMap))}},
excepted that I'm hoping someone can come with a less crappy name than
{{fullCollection}}.
More generally, on the indexing of frozen collections, indexing on the entire
collection should be relatively simple but indexing on values and keys will
require new indexes implementation (new subclasses of {{CompositesIndex}}) and
so this should definitively be pushed to a follow-up ticket imo. Not even sure
said ticket should be targeted at 2.1.
> Extend freezing to collections
> --
>
> Key: CASSANDRA-7859
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7859
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sylvain Lebresne
>Assignee: Tyler Hobbs
> Fix For: 2.1.1
>
>
> This is the follow-up to CASSANDRA-7857, to extend {{frozen}} to collections.
> This will allow things like {{map>>}} for
> instance, as well as allowing {{frozen}} collections in PK columns.
> Additionally (and that's alsmot a separate ticket but I figured we can start
> discussing it here), we could decide that tuple is a frozen type by default.
> This means that we would allow {{tuple}} without needing to add
> {{frozen}}, but we would require {{frozen}} for complex type inside tuple, so
> {{tuple>}} would be rejected, but not {{tuple frozen>>}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7159) sstablemetadata command should print some more stuff
[ https://issues.apache.org/jira/browse/CASSANDRA-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151548#comment-14151548 ] Vladislav Sinjavin commented on CASSANDRA-7159: --- Hi Jeremiah! Just a gentle reminder about the patch review. Thanks in advance. > sstablemetadata command should print some more stuff > > > Key: CASSANDRA-7159 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7159 > Project: Cassandra > Issue Type: Improvement > Components: Tools >Reporter: Jeremiah Jordan >Assignee: Vladislav Sinjavin >Priority: Trivial > Labels: lhf > Fix For: 2.0.11 > > Attachments: > CASSANDRA-7159_-_sstablemetadata_command_should_print_some_more_stuff.patch > > > It would be nice if the sstablemetadata command printed out some more of the > stuff we track. Like the Min/Max column names and the min/max token in the > file. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-8014) NPE in Message.java line 324
Peter Haggerty created CASSANDRA-8014: - Summary: NPE in Message.java line 324 Key: CASSANDRA-8014 URL: https://issues.apache.org/jira/browse/CASSANDRA-8014 Project: Cassandra Issue Type: Bug Components: Core Environment: Cassandra 2.0.9 Reporter: Peter Haggerty Attachments: NPE_Message.java_line-324.txt We received this when a server was rebooting and attempted to shut Cassandra down while it was still quite busy. While it's normal for us to have a handful of the RejectedExecution exceptions on a sudden shutdown like this these NPEs in Message.java are new. The attached file include the logs from "StorageServiceShutdownHook" to the "Logging initialized" after the server restarts and Cassandra comes back up. ERROR [pool-10-thread-2] 2014-09-29 08:33:44,055 Message.java (line 324) Unexpected throwable while invoking! java.lang.NullPointerException at com.thinkaurelius.thrift.util.mem.Buffer.size(Buffer.java:83) at com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.expand(FastMemoryOutputTransport.java:84) at com.thinkaurelius.thrift.util.mem.FastMemoryOutputTransport.write(FastMemoryOutputTransport.java:167) at org.apache.thrift.transport.TFramedTransport.flush(TFramedTransport.java:156) at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:55) at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39) at com.thinkaurelius.thrift.Message.invoke(Message.java:314) at com.thinkaurelius.thrift.Message$Invocation.execute(Message.java:90) at com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:638) at com.thinkaurelius.thrift.TDisruptorServer$InvocationHandler.onEvent(TDisruptorServer.java:632) at com.lmax.disruptor.WorkProcessor.run(WorkProcessor.java:112) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7953) RangeTombstones not merging during compaction
[
https://issues.apache.org/jira/browse/CASSANDRA-7953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14151434#comment-14151434
]
Marcus Eriksson commented on CASSANDRA-7953:
It might not be safe to change the comparator for this, a proper fix should
probably be in RangeTombstone.Tracker and remove all unnecessary RTs (not only
the ones that have the same start point). It might not be trivial in our new
(since CASSANDRA-4180) single-pass compaction though
> RangeTombstones not merging during compaction
> -
>
> Key: CASSANDRA-7953
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7953
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.1
>Reporter: Marcus Olsson
>Priority: Minor
> Labels: compaction, deletes, tombstone
> Attachments: 0001-7953-v2.patch, CASSANDRA-7953-1.patch,
> CASSANDRA-7953.patch
>
>
> When performing a compaction on two sstables that contain the same
> RangeTombstone with different timestamps, the tombstones are not merged in
> the new sstable.
> This has been tested using cassandra 2.1 with the following table:
> {code}
> CREATE TABLE test(
> key text,
> column text,
> data text,
> PRIMARY KEY(key, column)
> );
> {code}
> And then doing the following:
> {code}
> INSERT INTO test (key, column, data) VALUES ("1", "1", "1"); // If the
> sstable only contains tombstones during compaction it seems that the sstable
> either gets removed or isn't created (but that could probably be a separate
> JIRA issue).
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2"); // The inserts
> are not actually needed, since the deletes create tombstones either way.
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> INSERT INTO test (key, column, data) VALUES ("1", "2", "2");
> DELETE FROM test WHERE key="1" AND column="2";
> nodetool flush
> nodetool compact
> {code}
> When checking with the SSTableExport tool two tombstones exists in the
> compacted sstable. This can be repeated, resulting in more and more
> tombstones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
