[jira] [Created] (CASSANDRA-10464) "nodetool compactionhistory" output should be sorted on compacted_at column and the timestamp shown in human readable format
Wei Deng created CASSANDRA-10464: Summary: "nodetool compactionhistory" output should be sorted on compacted_at column and the timestamp shown in human readable format Key: CASSANDRA-10464 URL: https://issues.apache.org/jira/browse/CASSANDRA-10464 Project: Cassandra Issue Type: Improvement Reporter: Wei Deng Priority: Minor "nodetool compactionhistory" (introduced in CASSANDRA-5078) is a useful tool for Cassandra DBAs. However, the current output limits its usefulness without some additional parsing. We should improve it in the following two areas: 1. The output should be sorted on the compacted_at column, so that the most recently finished compaction will show up last (which is what the DBAs would expect); 2. The compacted_at column should be printed in human-readable timestamp. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10445) Cassandra-stress throws max frame size error when SSL certification is enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945157#comment-14945157
]
Philip Thompson commented on CASSANDRA-10445:
-
If you compile and use the cassandra stress from trunk against your 2.1
cluster, does this still reproduce?
> Cassandra-stress throws max frame size error when SSL certification is enabled
> --
>
> Key: CASSANDRA-10445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10445
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Goldberg
> Fix For: 2.1.x
>
>
> Running cassandra-stress when SSL is enabled gives the following error and
> does not finish executing:
> {quote}
> cassandra-stress write n=100
> Exception in thread "main" java.lang.RuntimeException:
> org.apache.thrift.transport.TTransportException: Frame size (352518912)
> larger than max length (15728640)!
> at
> org.apache.cassandra.stress.settings.StressSettings.getRawThriftClient(StressSettings.java:144)
> at
> org.apache.cassandra.stress.settings.StressSettings.getRawThriftClient(StressSettings.java:110)
> at
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpacesThrift(SettingsSchema.java:111)
> at
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:59)
> at
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:205)
> at org.apache.cassandra.stress.StressAction.run(StressAction.java:55)
> at org.apache.cassandra.stress.Stress.main(Stress.java:109)
> {quote}
> I was able to reproduce this issue consistently via the following steps:
> 1) Spin up 3 node cassandra cluster running 2.1.8
> 2) Perform cassandra-stress write n=100
> 3) Everything works!
> 4) Generate keystore and truststore for each node in the cluster and
> distribute appropriately
> 5) Modify cassandra.yaml on each node to enable SSL:
> client_encryption_options:
> enabled: true
> keystore: /
> # require_client_auth: false
> # Set trustore and truststore_password if require_client_auth is true
> truststore: /
> truststore_password:
> # More advanced defaults below:
> protocol: ssl
> 6) Restart each node.
> 7) Perform cassandra-stress write n=100
> 8) Get Frame Size error, cassandra-stress fails
> This may be related to CASSANDRA-9325.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10445) Cassandra-stress throws max frame size error when SSL certification is enabled
[
https://issues.apache.org/jira/browse/CASSANDRA-10445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-10445:
Fix Version/s: 2.1.x
> Cassandra-stress throws max frame size error when SSL certification is enabled
> --
>
> Key: CASSANDRA-10445
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10445
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sam Goldberg
> Fix For: 2.1.x
>
>
> Running cassandra-stress when SSL is enabled gives the following error and
> does not finish executing:
> {quote}
> cassandra-stress write n=100
> Exception in thread "main" java.lang.RuntimeException:
> org.apache.thrift.transport.TTransportException: Frame size (352518912)
> larger than max length (15728640)!
> at
> org.apache.cassandra.stress.settings.StressSettings.getRawThriftClient(StressSettings.java:144)
> at
> org.apache.cassandra.stress.settings.StressSettings.getRawThriftClient(StressSettings.java:110)
> at
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpacesThrift(SettingsSchema.java:111)
> at
> org.apache.cassandra.stress.settings.SettingsSchema.createKeySpaces(SettingsSchema.java:59)
> at
> org.apache.cassandra.stress.settings.StressSettings.maybeCreateKeyspaces(StressSettings.java:205)
> at org.apache.cassandra.stress.StressAction.run(StressAction.java:55)
> at org.apache.cassandra.stress.Stress.main(Stress.java:109)
> {quote}
> I was able to reproduce this issue consistently via the following steps:
> 1) Spin up 3 node cassandra cluster running 2.1.8
> 2) Perform cassandra-stress write n=100
> 3) Everything works!
> 4) Generate keystore and truststore for each node in the cluster and
> distribute appropriately
> 5) Modify cassandra.yaml on each node to enable SSL:
> client_encryption_options:
> enabled: true
> keystore: /
> # require_client_auth: false
> # Set trustore and truststore_password if require_client_auth is true
> truststore: /
> truststore_password:
> # More advanced defaults below:
> protocol: ssl
> 6) Restart each node.
> 7) Perform cassandra-stress write n=100
> 8) Get Frame Size error, cassandra-stress fails
> This may be related to CASSANDRA-9325.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10412: Reviewer: Paulo Motta > Could not initialize class org.apache.cassandra.config.DatabaseDescriptor > - > > Key: CASSANDRA-10412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10412 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OS: Windows 2012 R2 > Java JRE: 1.8.0_51 >Reporter: Eric Simmons >Assignee: Carl Yeksigian >Priority: Minor > Attachments: cassandra-env.ps1, cassandra.yaml > > > We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however > we can use the same environment to start version 2.1.2 > I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference. > I have also attached the system.log file displaying the error. > I have also included an excerpt of the log file showing the stack trace of > the error. > ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 > DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.config.DatabaseDescriptor > at > org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > ~[na:1.8.0_51] > at java.util.concurrent.FutureTask.runAndReset(Unknown Source) > ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown > Source) ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) ~[na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > [na:1.8.0_51] > at java.lang.Thread.run(Unknown Source) [na:1.8.0_51] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10449) OOM on bootstrap due to long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945149#comment-14945149
]
Philip Thompson commented on CASSANDRA-10449:
-
[~yukim], do you want to look at this as well?
> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10242) Validate rack information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10242: Reviewer: Paulo Motta > Validate rack information on startup > > > Key: CASSANDRA-10242 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10242 > Project: Cassandra > Issue Type: Improvement >Reporter: Jonathan Ellis >Assignee: Carl Yeksigian > Fix For: 2.1.x > > > Moving to a new rack means that different data should be stored on a node. > We already persist rack information in a system table; we should fail startup > if this doesn't match what the snitch thinks it should be. (Either the > snitch is wrong, and needs to be fixed, or the machine has been moved and > needs to be rebootstrapped.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10389) Repair session exception Validation failed
[
https://issues.apache.org/jira/browse/CASSANDRA-10389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Philip Thompson updated CASSANDRA-10389:
Fix Version/s: 2.2.x
> Repair session exception Validation failed
> --
>
> Key: CASSANDRA-10389
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10389
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Debian 8, Java 1.8.0_60, Cassandra 2.2.1 (datastax
> compilation)
>Reporter: Jędrzej Sieracki
> Fix For: 2.2.x
>
>
> I'm running a repair on a ring of nodes, that was recently extented from 3 to
> 13 nodes. The extension was done two days ago, the repair was attempted
> yesterday.
> {quote}
> [2015-09-22 11:55:55,266] Starting repair command #9, repairing keyspace
> perspectiv with repair options (parallelism: parallel, primary range: false,
> incremental: true, job threads: 1, ColumnFamilies: [], dataCenters: [],
> hosts: [], # of ranges: 517)
> [2015-09-22 11:55:58,043] Repair session 1f7c50c0-6110-11e5-b992-9f13fa8664c8
> for range (-5927186132136652665,-5917344746039874798] failed with error
> [repair #1f7c50c0-6110-11e5-b992-9f13fa8664c8 on
> perspectiv/stock_increment_agg, (-5927186132136652665,-5917344746039874798]]
> Validation failed in cblade1.XXX/XXX (progress: 0%)
> {quote}
> BTW, I am ignoring the LEAK errors for now, that's outside of the scope of
> the main issue:
> {quote}
> ERROR [Reference-Reaper:1] 2015-09-22 11:58:27,843 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@4d25ad8f) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@896826067:/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-73-big
> was not released before the reference was garbage collected
> {quote}
> I scrubbed the sstable with failed validation on cblade1 with nodetool scrub
> perspectiv stock_increment_agg:
> {quote}
> INFO [CompactionExecutor:1704] 2015-09-22 12:05:31,615 OutputHandler.java:42
> - Scrubbing
> BigTableReader(path='/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-83-big-Data.db')
> (345466609 bytes)
> INFO [CompactionExecutor:1703] 2015-09-22 12:05:31,615 OutputHandler.java:42
> - Scrubbing
> BigTableReader(path='/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-82-big-Data.db')
> (60496378 bytes)
> ERROR [Reference-Reaper:1] 2015-09-22 12:05:31,676 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@4ca8951e) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@114161559:/var/lib/cassandra/data/perspectiv/receipt_agg_total-76abb0625de711e59f6e0b7d98a25b6e/la-48-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-22 12:05:31,676 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@eeb6383) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1612685364:/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-83-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-22 12:05:31,676 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@1de90543) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@2058626950:/var/lib/cassandra/data/perspectiv/receipt_agg_total-76abb0625de711e59f6e0b7d98a25b6e/la-49-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-22 12:05:31,676 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@15616385) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1386628428:/var/lib/cassandra/data/perspectiv/receipt_agg_total-76abb0625de711e59f6e0b7d98a25b6e/la-47-big
> was not released before the reference was garbage collected
> INFO [CompactionExecutor:1703] 2015-09-22 12:05:35,098 OutputHandler.java:42
> - Scrub of
> BigTableReader(path='/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-82-big-Data.db')
> complete: 51397 rows in new sstable and 0 empty (tombstoned) rows dropped
> INFO [CompactionExecutor:1704] 2015-09-22 12:05:47,605 OutputHandler.java:42
> - Scrub of
> BigTableReader(path='/var/lib/cassandra/data/perspectiv/stock_increment_agg-840cad405de711e5b9929f13fa8664c8/la-83-big-Data.db')
> complete: 292600 rows in new sstable and 0 empty (tombstoned) rows dropped
> {quote}
> Now, after scrubbing, another repair was attempted, it did finish, but with
> lots of errors from
[jira] [Commented] (CASSANDRA-10393) LEAK DETECTED: a reference (org.apache.cassandra.utils.concurrent.Ref)
[
https://issues.apache.org/jira/browse/CASSANDRA-10393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945162#comment-14945162
]
Philip Thompson commented on CASSANDRA-10393:
-
[~yukim], can you look at this repair issue?
> LEAK DETECTED: a reference (org.apache.cassandra.utils.concurrent.Ref)
> --
>
> Key: CASSANDRA-10393
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10393
> Project: Cassandra
> Issue Type: Bug
> Environment: v 2.2.1 (from apt)
> -> lsb_release -a
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux 7.8 (wheezy)
> Release: 7.8
> Codename: wheezy
> -> java -version
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>Reporter: Christian Winther
> Labels: memory-leak, sstable
> Fix For: 2.2.x
>
>
> When trying to repair full on a table with the following schema my nodes
> stall
> and end up with spamming this
> I've recently changed the table from SizeTieredCompactionStrategy to
> LeveledCompactionStrategy.
> Coming from 2.1.9 -> 2.2.0 -> 2.2.1 i ran upgradesstable without issue as well
> When trying to full repair post compaction change, I got "out of order"
> errors. A few google searches later, I was told to "scrub" the keyspace - did
> that during the night (no problems logged, and no data lost)
> Now a repair just stalls and output memory leaks all over the place
> {code}
> CREATE KEYSPACE sessions WITH replication = {'class': 'SimpleStrategy',
> 'replication_factor': '3'} AND durable_writes = true;
> CREATE TABLE sessions.sessions (
> id text PRIMARY KEY,
> client_ip text,
> controller text,
> controller_action text,
> created timestamp,
> data text,
> expires timestamp,
> http_host text,
> modified timestamp,
> request_agent text,
> request_agent_bot boolean,
> request_path text,
> site_id int,
> user_id int
> ) WITH bloom_filter_fp_chance = 0.01
> AND caching = '{"keys":"NONE", "rows_per_partition":"NONE"}'
> AND comment = ''
> AND compaction = {'class':
> 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
> AND compression = {'sstable_compression':
> 'org.apache.cassandra.io.compress.LZ4Compressor'}
> AND dclocal_read_repair_chance = 0.1
> AND default_time_to_live = 0
> AND gc_grace_seconds = 864000
> AND max_index_interval = 2048
> AND memtable_flush_period_in_ms = 0
> AND min_index_interval = 128
> AND read_repair_chance = 0.0
> AND speculative_retry = '99.0PERCENTILE';
> {code}
> {code}
> ERROR [Reference-Reaper:1] 2015-09-24 10:25:28,475 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@4428a373) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@184765:/data/1/cassandra/sessions/sessions-77dd22f0ab9711e49cbc410c6b6f53a6/la-104037-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-24 10:25:28,475 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@368dd97) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@184765:/data/1/cassandra/sessions/sessions-77dd22f0ab9711e49cbc410c6b6f53a6/la-104037-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-24 10:25:28,475 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@66fb78be) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@184765:/data/1/cassandra/sessions/sessions-77dd22f0ab9711e49cbc410c6b6f53a6/la-104037-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-24 10:25:28,475 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@9fdd2e6) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1460906269:/data/1/cassandra/sessions/sessions-77dd22f0ab9711e49cbc410c6b6f53a6/la-104788-big
> was not released before the reference was garbage collected
> ERROR [Reference-Reaper:1] 2015-09-24 10:25:28,475 Ref.java:187 - LEAK
> DETECTED: a reference
> (org.apache.cassandra.utils.concurrent.Ref$State@84fcb91) to class
> org.apache.cassandra.io.sstable.format.SSTableReader$InstanceTidier@1460906269:/data/1/cassandra/sessions/sessions-77dd22f0ab9711e49cbc410c6b6f53a6/la-104788-big
> was not released before the reference was garbage collected
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945447#comment-14945447
]
Omri Iluz commented on CASSANDRA-10448:
---
all nodes are within one availability zone in Google's data center. We never
had any network issues and any network test I am running in parallel to the
repair session seems to return fine.
I thought this might be due to corruption in the sstables somewhere so I ran
scrub, but that also didn't help.
Any other ideas or things I can try ?
> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330
> for range (59694553044959221,86389982480621619] failed with error [repair
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Creating new streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.81.104 is complete
> WARN [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Starting streaming to /10.240.134.221
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Beginning stream session with /10.240.134.221
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13
> files(517391317 bytes)
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
> at
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
[jira] [Commented] (CASSANDRA-10438) Overwrites of rows in memtable produce incorrect deltas for indexing
[
https://issues.apache.org/jira/browse/CASSANDRA-10438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945552#comment-14945552
]
Ariel Weisberg commented on CASSANDRA-10438:
Unless I am mistaken I can revert the fix to onPrimaryKeyLivenessInfo and the
test still passes?
The fix itself and the description of the bug make sense to me. The test is
convincing in that it checks the contents of the update case. I'm just not sure
about onPrimaryKeyLivenessInfo.
I looked at the cassci results.
org.apache.cassandra.cql3.validation.operations.CreateTest.testCQL3PartitionKeyOnlyTable
is unusual, but I didn't reproduce it.
> Overwrites of rows in memtable produce incorrect deltas for indexing
>
>
> Key: CASSANDRA-10438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10438
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0 rc2
>
>
> When a row in the memtable is updated, the delta is supplied to any
> registered indexer. This consists of two {{Row}} objects, representing the
> old and new data in the memtable. As per its javadoc, the contract of
> {{Index.Indexer::updateRow}} is that these old & new rows contain only the
> changed columns, so any column which was not affected by the update will
> appear in neither the new nor old row. The {{RowDiffListener::onCell}} method
> in {{SecondaryIndexManager.WriteTimeTransaction::onUpdated}} which produces
> these deltas uses a reference equality check, where it should be checking
> object equality. This results in unchanged, prexisting cells appearing in the
> {{toInsert}} row.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10437) Remove offheap_objects option until 9472 re-introduces them
[
https://issues.apache.org/jira/browse/CASSANDRA-10437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945466#comment-14945466
]
Ariel Weisberg commented on CASSANDRA-10437:
Created a branch for cassci to run it. Will report back.
> Remove offheap_objects option until 9472 re-introduces them
> ---
>
> Key: CASSANDRA-10437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10437
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
> Fix For: 3.0.0 rc2
>
> Attachments: 0001-Remove-offheap_objects-option.txt
>
>
> We need to send a meaningful error message if user try to use
> {{offheap_objects}} in 3.0 since it's not supported currently (pending
> CASSANDRA-9472). And document the current removal in the NEWS file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945579#comment-14945579
]
Paulo Motta commented on CASSANDRA-10451:
-
Created [dtest PR|https://github.com/riptano/cassandra-dtest/pull/583] with
fixes. Basically ccm/dtest merges system.log and debug.log, so info/warn/error
statements are duplicated. Modified tests to only assert logs are present, and
not count them.
> Fix
> batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
> on CassCI
> --
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10455) Fix pep8 compliance in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945596#comment-14945596 ] Philip Thompson commented on CASSANDRA-10455: - I missed this being broken when i reviewed CASSANDRA-9855. http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/210/changes > Fix pep8 compliance in cqlsh.py > --- > > Key: CASSANDRA-10455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10455 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Philip Thompson > Labels: cqlsh > Fix For: 3.0.0 rc2 > > > cqlsh has fallen out of pep8 compliance: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_pep8_compliance/ > [~philipthompson] has said off-JIRA that he'll fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10453) Fix compression_cql_options_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945583#comment-14945583 ] Paulo Motta commented on CASSANDRA-10453: - Created [dtest PR|https://github.com/riptano/cassandra-dtest/pull/583] with fixes. Basically ccm/dtest merges system.log and debug.log, so info/warn/error statements are duplicated. Modified tests to only assert logs are present, and not count them. > Fix compression_cql_options_test dtest > -- > > Key: CASSANDRA-10453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This has been failing hard for a while: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ > This regression, like CASSANDRA-10451, started when the recent log changes > were introduced: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes > I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] > again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10455) Fix pep8 compliance in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Thompson updated CASSANDRA-10455: Labels: cqlsh (was: ) > Fix pep8 compliance in cqlsh.py > --- > > Key: CASSANDRA-10455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10455 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Philip Thompson > Labels: cqlsh > Fix For: 3.0.0 rc2 > > > cqlsh has fallen out of pep8 compliance: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_pep8_compliance/ > [~philipthompson] has said off-JIRA that he'll fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10455) Fix pep8 compliance in cqlsh.py
Jim Witschey created CASSANDRA-10455: Summary: Fix pep8 compliance in cqlsh.py Key: CASSANDRA-10455 URL: https://issues.apache.org/jira/browse/CASSANDRA-10455 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Philip Thompson Fix For: 3.0.0 rc2 cqlsh has fallen out of pep8 compliance: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_pep8_compliance/ [~philipthompson] has said off-JIRA that he'll fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10454) fix failing cqlsh COPY dtests
Jim Witschey created CASSANDRA-10454: Summary: fix failing cqlsh COPY dtests Key: CASSANDRA-10454 URL: https://issues.apache.org/jira/browse/CASSANDRA-10454 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Jim Witschey The proximate cause of these failures: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_null_as_null_indicator/ http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_copy_tests/CqlshCopyTest/test_undefined_as_null_indicator/ is an error in the dtest logic. I'll take this one on; I've filed a dtest PR here: https://github.com/riptano/cassandra-dtest/pull/582 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10438) Overwrites of rows in memtable produce incorrect deltas for indexing
[
https://issues.apache.org/jira/browse/CASSANDRA-10438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ariel Weisberg updated CASSANDRA-10438:
---
Reviewer: Ariel Weisberg
> Overwrites of rows in memtable produce incorrect deltas for indexing
>
>
> Key: CASSANDRA-10438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10438
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Sam Tunnicliffe
>Assignee: Sam Tunnicliffe
> Fix For: 3.0.0 rc2
>
>
> When a row in the memtable is updated, the delta is supplied to any
> registered indexer. This consists of two {{Row}} objects, representing the
> old and new data in the memtable. As per its javadoc, the contract of
> {{Index.Indexer::updateRow}} is that these old & new rows contain only the
> changed columns, so any column which was not affected by the update will
> appear in neither the new nor old row. The {{RowDiffListener::onCell}} method
> in {{SecondaryIndexManager.WriteTimeTransaction::onUpdated}} which produces
> these deltas uses a reference equality check, where it should be checking
> object equality. This results in unchanged, prexisting cells appearing in the
> {{toInsert}} row.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10242) Validate rack information on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945762#comment-14945762
]
Paulo Motta commented on CASSANDRA-10242:
-
Patch LGTM overall, could you just add a simple dtest changing the rack of a
single node and check the node will fail to initialize? {{replication_test.py}}
have some example of changing snitch/rack information.
Also, is there any reason you changed the default rack and dc assignments of
{{conf/cassandra-rackdc.properties}} ?
> Validate rack information on startup
>
>
> Key: CASSANDRA-10242
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10242
> Project: Cassandra
> Issue Type: Improvement
>Reporter: Jonathan Ellis
>Assignee: Carl Yeksigian
> Fix For: 2.1.x
>
>
> Moving to a new rack means that different data should be stored on a node.
> We already persist rack information in a system table; we should fail startup
> if this doesn't match what the snitch thinks it should be. (Either the
> snitch is wrong, and needs to be fixed, or the machine has been moved and
> needs to be rebootstrapped.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10456) fix deprecated_repair_test dtests
Jim Witschey created CASSANDRA-10456: Summary: fix deprecated_repair_test dtests Key: CASSANDRA-10456 URL: https://issues.apache.org/jira/browse/CASSANDRA-10456 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Jim Witschey All the deprecated_repair_test dtests are failing on CassCI. I believe the immediate cause is some recent changes to logs and how ccm handles them, like the failures in CASSANDRA-10451 and CASSANDRA-10453. Test failures on CassCI here: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/deprecated_repair_test/ I'm assigning myself to track this, in case there are other failures to deal with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10456) fix deprecated_repair_test dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945720#comment-14945720 ] Yuki Morishita commented on CASSANDRA-10456: I think these are from log change. Can you try with the latest ccm? My PR to fix log was merged. (https://github.com/pcmanus/ccm/pull/380) > fix deprecated_repair_test dtests > - > > Key: CASSANDRA-10456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10456 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Jim Witschey > Fix For: 3.0.0 rc2 > > > All the deprecated_repair_test dtests are failing on CassCI. I believe the > immediate cause is some recent changes to logs and how ccm handles them, like > the failures in CASSANDRA-10451 and CASSANDRA-10453. Test failures on CassCI > here: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/deprecated_repair_test/ > I'm assigning myself to track this, in case there are other failures to deal > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945744#comment-14945744 ] Joshua McKenzie commented on CASSANDRA-10412: - Windows timer init's pretty flexible, so move it around in that method at-will. > Could not initialize class org.apache.cassandra.config.DatabaseDescriptor > - > > Key: CASSANDRA-10412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10412 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OS: Windows 2012 R2 > Java JRE: 1.8.0_51 >Reporter: Eric Simmons >Assignee: Carl Yeksigian >Priority: Minor > Fix For: 2.2.x > > Attachments: cassandra-env.ps1, cassandra.yaml > > > We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however > we can use the same environment to start version 2.1.2 > I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference. > I have also attached the system.log file displaying the error. > I have also included an excerpt of the log file showing the stack trace of > the error. > ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 > DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.config.DatabaseDescriptor > at > org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > ~[na:1.8.0_51] > at java.util.concurrent.FutureTask.runAndReset(Unknown Source) > ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown > Source) ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) ~[na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > [na:1.8.0_51] > at java.lang.Thread.run(Unknown Source) [na:1.8.0_51] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg updated CASSANDRA-9602: -- Reviewer: Ariel Weisberg > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[
https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945671#comment-14945671
]
Paulo Motta commented on CASSANDRA-10412:
-
Overall looks good, but I'd rather not add the {{Config.setEmbeddedService()}}
method only for this exit check on {{DatabaseDescriptor}} if there are
alternatives.
Can't we move the Windows timer period initialization to after
{{DatabaseDescriptor.forceStaticInitialization()}} on
{{CassandraDaemon.activate()}} ? The {{DatabaseDescriptor}} static
initialization will be done anyway before the timer setup, so unless there's
some nit I'm not aware of with this Windows timer period thing I don't see a
problem with this approach. We'd still need to throw
{{ExceptionInInitializerError}} after catching a {{ConfigurationException}} on
{{DatabaseDescriptor.forceStaticInitialization()}}, so
{{CassandraDaemon.activate()}} would fail and exit with a nice message after a
configuration error.
> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.config.DatabaseDescriptor
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> ~[na:1.8.0_51]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10456) fix deprecated_repair_test dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945739#comment-14945739 ] Jim Witschey commented on CASSANDRA-10456: -- [~yukim] Thanks, and sorry I wasn't clear. I'll rerun the tests; based on running it locally, I think that'll fix it. > fix deprecated_repair_test dtests > - > > Key: CASSANDRA-10456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10456 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Jim Witschey > Fix For: 3.0.0 rc2 > > > All the deprecated_repair_test dtests are failing on CassCI. I believe the > immediate cause is some recent changes to logs and how ccm handles them, like > the failures in CASSANDRA-10451 and CASSANDRA-10453. Test failures on CassCI > here: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/deprecated_repair_test/ > I'm assigning myself to track this, in case there are other failures to deal > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945735#comment-14945735
]
Paulo Motta commented on CASSANDRA-10448:
-
[~mroi] can you please attach debug.log of both nodes for the failure period?
> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330
> for range (59694553044959221,86389982480621619] failed with error [repair
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Creating new streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.81.104 is complete
> WARN [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Starting streaming to /10.240.134.221
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Beginning stream session with /10.240.134.221
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13
> files(517391317 bytes)
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
> at
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
>
[jira] [Commented] (CASSANDRA-9602) EACH_QUORUM READ support needed
[ https://issues.apache.org/jira/browse/CASSANDRA-9602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945782#comment-14945782 ] Ariel Weisberg commented on CASSANDRA-9602: --- What is the doc impact here? I looked at the [2.2 docs|http://docs.datastax.com/en/cassandra/2.2/cassandra/dml/dmlConfigConsistency.html] and it makes it seem like EACH_QUORUM for reads is already supported, but the code makes it look like it would throw InvalidRequestException? Do we need to have the 2.2 and earlier docs updated? How is this tested? I looked at consistency_test.py test and I don't think it tests combinations with EACH_QUORUM for reads. It looks like ConsistencyLevel is unit testable, but I don't see a test for the existing code. Could you add tests for the code that changed? [Is dcsEndpoints something worth caching in some way?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR225] [What is the expected load balancing behavior here?|https://github.com/apache/cassandra/compare/trunk...carlyeks:ticket/9602#diff-6f46fd4f8a36f42512ae5f848aee033eR244] Is it (and should it) hit the same nodes in each DC every time? > EACH_QUORUM READ support needed > --- > > Key: CASSANDRA-9602 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9602 > Project: Cassandra > Issue Type: Sub-task >Reporter: Scott Guminy >Assignee: Carl Yeksigian > Labels: client-impacting, doc-impacting > Fix For: 3.x > > > EACH_QUORUM consistency for READ should be added. > This bug https://issues.apache.org/jira/browse/CASSANDRA-3272 says it is not > needed ever, however I have a use case where I need it. I think the decision > made was incorrect. Here's why... > > My application has two key pieces: > > # *End user actions* which add/modify data in the system. End users > typically access the application from only one Data Center and only see their > own data > # *Scheduled business logic tasks* which run from any node in any data > center. These tasks process data added by the end users in an asynchronous > way > > *End user actions must have the highest degree of availability.* Users must > always be able to add data to the system. The data will be processed later. > To support this, end user actions will use *LOCAL_QUORUM Read and Write > Consistency*. > > Scheduled tasks don't need to have a high degree of availability but MUST > operate on the most up to date data. *The tasks will run with EACH_QUORUM* > to ensure that no matter how many data centers we have, we always READ the > latest data. This approach allows us some amount of fault tolerance. > > The problem is that EACH_QUORUM is not a valid READ consistency level. This > mean I have no alternative but to use ALL. ALL will work, but is not the > best since it offers support for ZERO failures. I would prefer EACH_QUORUM > since it can support some failures in each data center. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10458) cqlshrc: add option to always use ssl
Matt Wringe created CASSANDRA-10458: --- Summary: cqlshrc: add option to always use ssl Key: CASSANDRA-10458 URL: https://issues.apache.org/jira/browse/CASSANDRA-10458 Project: Cassandra Issue Type: Improvement Reporter: Matt Wringe I am currently running on a system in which my cassandra cluster is only accessible over tls. The cqlshrc file is used to specify the host, the certificates and other configurations, but one option its missing is to always connect over ssl. I would like to be able to call 'cqlsh' instead of always having to specify 'cqlsh --ssl' -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9304) COPY TO improvements
[
https://issues.apache.org/jira/browse/CASSANDRA-9304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945873#comment-14945873
]
Tyler Hobbs commented on CASSANDRA-9304:
Overall the patch is definitely a nice improvement! Most of my review comments
are about using more idiomatic python.
Imports:
* In the imports, StringIO is imported later. Also, to avoid flake8 warnings,
add {{# noqa}} to the {{from io import StringIO}} line.
ImportExportConfig:
* The way that checks for unhandled options are performed is kind of strange.
In perform_csv_import() they're checked immediately, but in
perform_csv_export() it's deferred to ExportTask. Additionally, a lot of
functions seem to modify the options inside an ImportExportConfig instance,
which is somewhat unexpected behavior and seems likely to result in bugs in the
future.
* In Python it's pretty unusual to use a class to only store mutable data, so I
would replace the ImportExportConfig class with a function that returns a tuple
(e.g. {{(csv_options, dialect_options, unrecognized_options)}}) or a dict.
perform_csv_import():
* Why do {{csv_options = config.csv_options}} if it's only used once a couple
of lines later?
* As a matter of code style, avoid using tuple unpacking unless you're
actually unpacking a tuple or the assignments are very trivial (e.g. {{a, b =
None, None}})
ExportTask:
* The class should inherit from object
* get_ranges():
** There's no need to use a lambda sorting key on a list of tuples. Tuples are
naturally sorted sanely.
** Instead of {{del hosts\[:\]}}, just say {{hosts = \[\]}}. You can also
remove {{hosts = \[hostname\]}} above.
** Instead of doing {{for entry in ring}} and then using {{entry\[0\]}} and
{{entry\[1\]}}, you can unpack the tuple in the loop: {{for token, replicas in
ring:}}
** The final {{ranges.append()}} call could use a comment for explanation. If
you make the suggested changes to {{hosts}}, just use {{ranges\[-1\]\[1\]}} for
the hosts (unless it's empty). This approach is a little more obvious for
readers.
* In {{send_initial_work()}}, it's idiomatic in python to use {{_}} for the
name of an unused variable, so the loop should be: {{for _ in
xrange(num_parallel_jobs)}}.
ExportProcess:
* In {{start_job()}}, it's not clear what would result in an IndexError and why
we're ignoring it. Try to limit try/excepts to the minimum number of lines
they need to contain, and add a comment explaining what's going on there.
* ExportSession should be a separate top-level class instead of a nested one.
(It's pretty unusual to nest classes.) Also, it should inherit from object().
* I would rename {{handle_result}} to {{attach_callbacks}} and rename
{{return_result}} to {{write_rows_to_csv}}.
* The host selection code in {{get_session}} is over-complicated. How about
something like:
{code}
new_hosts = [h for h in hosts if h not in self.hosts_to_sessions]
if new_hosts:
host = new_hosts[0]
# open Cluster, etc
else:
host = min(hosts, key=lambda h: self.hosts_to_sessions[h].jobs)
session = self.hosts_to_sessions[host]
session.jobs += 1
return session
{code}
General:
* Try to add a few more code comments explaining what's going on at a high
level. Documenting method return values is also good (since there's no type
information about that).
* You may want to put the csv-related classes and functions into separate
modules under {{pylib}}.
> COPY TO improvements
>
>
> Key: CASSANDRA-9304
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9304
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
>Reporter: Jonathan Ellis
>Assignee: Stefania
>Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.x
>
>
> COPY FROM has gotten a lot of love. COPY TO not so much. One obvious
> improvement could be to parallelize reading and writing (write one page of
> data while fetching the next).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7645) cqlsh: show partial trace if incomplete after max_trace_wait
[
https://issues.apache.org/jira/browse/CASSANDRA-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945874#comment-14945874
]
Paulo Motta commented on CASSANDRA-7645:
+1, could you provide 2.2+ patches? apparently cqlsh was moved from bin/cqlsh
to bin/cqlsh.py, so the patche does not apply to 2.2 and 3.0. Thanks!
> cqlsh: show partial trace if incomplete after max_trace_wait
>
>
> Key: CASSANDRA-7645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7645
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Carl Yeksigian
>Priority: Trivial
> Fix For: 2.1.x
>
>
> If a trace hasn't completed within {{max_trace_wait}}, cqlsh will say the
> trace is unavailable and not show anything. It (and the underlying python
> driver) determines when the trace is complete by checking if the {{duration}}
> column in {{system_traces.sessions}} is non-null. If {{duration}} is null
> but we still have some trace events when the timeout is hit, cqlsh should
> print whatever trace events we have along with a warning about it being
> incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[
https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945931#comment-14945931
]
Paulo Motta commented on CASSANDRA-10412:
-
I think we should keep as few {{System.exit}} calls as possible spread around
the code, and {{CassandraDaemon}} already has a {{runManaged}} field to supress
{{System.exit()}} on errors, so we would be duplicating that functionality with
{{DatabaseDescriptor.setEmbeddedService()}}.
I don't think {{DatabaseDescriptor}} became more difficult to use, we just need
to make sure it's used after {{DatabaseDescriptor.forceStaticInitialization()}}
statement on {{CassandraDaemon.activate()}}. Maybe we could rename this method
or add a notice to {{CassandraDaemon.activate()}} to make this more clear? Do
you see any situation in which we would need to access {{DatabaseDescriptor}}
before it's initialization on {{CassandraDaemon.activate()}}?
> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.config.DatabaseDescriptor
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> ~[na:1.8.0_51]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[
https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945797#comment-14945797
]
Carl Yeksigian commented on CASSANDRA-10412:
It is an easy fix, but I'd rather fix the prior mistake so that it hopefully
doesn't happen again. I provided the history behind how this broke to show that
it's broken a few times and is very fragile. The changes have made
{{DatabaseDescriptor}} more difficult to use, and it's to support a secondary
use case whereas for our primary use case, it's become brittle.
> Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
> -
>
> Key: CASSANDRA-10412
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10412
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: OS: Windows 2012 R2
> Java JRE: 1.8.0_51
>Reporter: Eric Simmons
>Assignee: Carl Yeksigian
>Priority: Minor
> Fix For: 2.2.x
>
> Attachments: cassandra-env.ps1, cassandra.yaml
>
>
> We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however
> we can use the same environment to start version 2.1.2
> I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference.
> I have also attached the system.log file displaying the error.
> I have also included an excerpt of the log file showing the stack trace of
> the error.
> ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482
> DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor
> java.lang.NoClassDefFoundError: Could not initialize class
> org.apache.cassandra.config.DatabaseDescriptor
> at
> org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122)
> ~[apache-cassandra-2.2.1.jar:2.2.1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> ~[na:1.8.0_51]
> at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
> ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown
> Source) ~[na:1.8.0_51]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown
> Source) ~[na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> [na:1.8.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> [na:1.8.0_51]
> at java.lang.Thread.run(Unknown Source) [na:1.8.0_51]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10437) Remove offheap_objects option until 9472 re-introduces them
[
https://issues.apache.org/jira/browse/CASSANDRA-10437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945824#comment-14945824
]
Ariel Weisberg commented on CASSANDRA-10437:
[dtests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-C-10437-dtest/1/#showFailuresLink]
and
[utests|http://cassci.datastax.com/view/Dev/view/aweisberg/job/aweisberg-C-10437-testall/1/#showFailuresLink]
I went through the results and it seems to match trunk for the most part. None
of the failures looked related to me. I kicked off another test-all and dtest
just to see what repeats and what doesn't. Otherwise +1.
> Remove offheap_objects option until 9472 re-introduces them
> ---
>
> Key: CASSANDRA-10437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10437
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
> Fix For: 3.0.0 rc2
>
> Attachments: 0001-Remove-offheap_objects-option.txt
>
>
> We need to send a meaningful error message if user try to use
> {{offheap_objects}} in 3.0 since it's not supported currently (pending
> CASSANDRA-9472). And document the current removal in the NEWS file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10437) Remove offheap_objects option until 9472 re-introduces them
[
https://issues.apache.org/jira/browse/CASSANDRA-10437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945825#comment-14945825
]
Ariel Weisberg commented on CASSANDRA-10437:
Oh, actually what is the doc impact here? Has that been taken care of?
> Remove offheap_objects option until 9472 re-introduces them
> ---
>
> Key: CASSANDRA-10437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10437
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
> Fix For: 3.0.0 rc2
>
> Attachments: 0001-Remove-offheap_objects-option.txt
>
>
> We need to send a meaningful error message if user try to use
> {{offheap_objects}} in 3.0 since it's not supported currently (pending
> CASSANDRA-9472). And document the current removal in the NEWS file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (CASSANDRA-7645) cqlsh: show partial trace if incomplete after max_trace_wait
[
https://issues.apache.org/jira/browse/CASSANDRA-7645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945874#comment-14945874
]
Paulo Motta edited comment on CASSANDRA-7645 at 10/6/15 9:39 PM:
-
\+1, could you provide 2.2+ patches? apparently cqlsh was moved from bin/cqlsh
to bin/cqlsh.py, so the patche does not apply to 2.2 and 3.0. Thanks!
was (Author: pauloricardomg):
+1, could you provide 2.2+ patches? apparently cqlsh was moved from bin/cqlsh
to bin/cqlsh.py, so the patche does not apply to 2.2 and 3.0. Thanks!
> cqlsh: show partial trace if incomplete after max_trace_wait
>
>
> Key: CASSANDRA-7645
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7645
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
>Reporter: Tyler Hobbs
>Assignee: Carl Yeksigian
>Priority: Trivial
> Fix For: 2.1.x
>
>
> If a trace hasn't completed within {{max_trace_wait}}, cqlsh will say the
> trace is unavailable and not show anything. It (and the underlying python
> driver) determines when the trace is complete by checking if the {{duration}}
> column in {{system_traces.sessions}} is non-null. If {{duration}} is null
> but we still have some trace events when the timeout is hit, cqlsh should
> print whatever trace events we have along with a warning about it being
> incomplete.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10457) fix failing jmx_metrics dtest
Jim Witschey created CASSANDRA-10457:
Summary: fix failing jmx_metrics dtest
Key: CASSANDRA-10457
URL: https://issues.apache.org/jira/browse/CASSANDRA-10457
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
{{jmxmetrics_test.py:TestJMXMetrics.begin_test}} is failing on CassCI; I've
reproduced it on OpenStack as well. Here's the failure:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/jmxmetrics_test/TestJMXMetrics/begin_test/
My first thought is that a fix may be as simple as changing the parameters to
stress between collecting the before and after metrics. I haven't debugged this
further than reproducing it, though.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10459) Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest
Jim Witschey created CASSANDRA-10459: Summary: Fix largecolumn_test.py:TestLargeColumn.cleanup_test dtest Key: CASSANDRA-10459 URL: https://issues.apache.org/jira/browse/CASSANDRA-10459 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey This test on large columns is failing: http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/largecolumn_test/TestLargeColumn/cleanup_test/ and it's been failing for a while: http://cassci.datastax.com/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/junit/largecolumn_test/TestLargeColumn/cleanup_test/history/ I've reproduced the failure on OpenStack, so it's not just a CassCI problem. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10460) Fix materialized_views_test.py:TestMaterializedViews.complex_mv_select_statements_test
Jim Witschey created CASSANDRA-10460: Summary: Fix materialized_views_test.py:TestMaterializedViews.complex_mv_select_statements_test Key: CASSANDRA-10460 URL: https://issues.apache.org/jira/browse/CASSANDRA-10460 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Carl Yeksigian This test: http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/materialized_views_test/TestMaterializedViews/complex_mv_select_statements_test/ fails on CassCI and when I run it manually on OpenStack. It's been failing for a while: http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/materialized_views_test/TestMaterializedViews/complex_mv_select_statements_test/history/ Assigning to [~carlyeks] for triage; feel free to reassign. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey
[
https://issues.apache.org/jira/browse/CASSANDRA-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14944705#comment-14944705
]
Marcus Eriksson commented on CASSANDRA-9126:
[~mambocab] it is likely this was due to either a corrupt sstable or overlap in
the LCS leveling, scrubbing and restarting solves both
> java.lang.RuntimeException: Last written key DecoratedKey >= current key
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: srinivasu gottipati
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue
> was raised in earlier versions and marked as closed. However it still appears
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing
> with this error.:
> {code}java.lang.RuntimeException: Last written key
> DecoratedKey(3462767860784856708,
> 354038323137333038305f3330325f31355f474d4543454f) >= current key
> DecoratedKey(3462334604624154281,
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
> at
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10453) Fix compression_cql_options_test dtest
Jim Witschey created CASSANDRA-10453: Summary: Fix compression_cql_options_test dtest Key: CASSANDRA-10453 URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Fix For: 3.0.0 rc2 This has been failing hard for a while: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ This regression, like CASSANDRA-10451, started when the recent log changes were introduced: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10453) Fix compression_cql_options_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta reassigned CASSANDRA-10453: --- Assignee: Paulo Motta > Fix compression_cql_options_test dtest > -- > > Key: CASSANDRA-10453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This has been failing hard for a while: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ > This regression, like CASSANDRA-10451, started when the recent log changes > were introduced: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes > I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] > again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Omri Iluz updated CASSANDRA-10448:
--
Attachment: casslogs.txt
System and debug logs attached from both nodes.
This is from another repair session today, after a scrub.
these logs are filtered by the stream id, let me know if the full logs can be
helpful (but they are big)
> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
> Attachments: casslogs.txt
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330
> for range (59694553044959221,86389982480621619] failed with error [repair
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Creating new streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.81.104 is complete
> WARN [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Starting streaming to /10.240.134.221
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Beginning stream session with /10.240.134.221
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13
> files(517391317 bytes)
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
> at
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
>
[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
[ https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946161#comment-14946161 ] Ariel Weisberg commented on CASSANDRA-7392: --- bq. Thank you for your hard work Ditto. +1 then. > Abort in-progress queries that time out > --- > > Key: CASSANDRA-7392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7392 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Critical > Fix For: 3.x > > > Currently we drop queries that time out before we get to them (because node > is overloaded) but not queries that time out while being processed. > (Particularly common for index queries on data that shouldn't be indexed.) > Adding the latter and logging when we have to interrupt one gets us a poor > man's "slow query log" for free. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
[ https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946104#comment-14946104 ] Stefania commented on CASSANDRA-7392: - Thank you for your hard work Ariel. I have rerun test-all on trunk and it completed successfully this time, test results look OK to me. > Abort in-progress queries that time out > --- > > Key: CASSANDRA-7392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7392 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Critical > Fix For: 3.x > > > Currently we drop queries that time out before we get to them (because node > is overloaded) but not queries that time out while being processed. > (Particularly common for index queries on data that shouldn't be indexed.) > Adding the latter and logging when we have to interrupt one gets us a poor > man's "slow query log" for free. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10461) Fix sstableverify_test dtest
Jim Witschey created CASSANDRA-10461: Summary: Fix sstableverify_test dtest Key: CASSANDRA-10461 URL: https://issues.apache.org/jira/browse/CASSANDRA-10461 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey The dtest for sstableverify is failing: http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/ It fails in the same way when I run it on OpenStack, so I don't think it's just a CassCI problem. [~slebresne] Looks like you made changes to this test recently: https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880 Could you have a look at the failure? I'm assigning you for triage, but feel free to reassign. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10462) Fix failing upgrade test
Jim Witschey created CASSANDRA-10462:
Summary: Fix failing upgrade test
Key: CASSANDRA-10462
URL: https://issues.apache.org/jira/browse/CASSANDRA-10462
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
The
{{upgrade_tests/paging_test.py:TestPagingWithDeletions.test_failure_threshold_deletions}}
dtest fails on CassCI:
http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_failure_threshold_deletions/
and has failed for a while:
http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_failure_threshold_deletions/history/
It fails identically when I run it manually on OpenStack, so I don't think it's
a CassCI problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10463) Fix failing compaction tests
Jim Witschey created CASSANDRA-10463: Summary: Fix failing compaction tests Key: CASSANDRA-10463 URL: https://issues.apache.org/jira/browse/CASSANDRA-10463 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Assignee: Yuki Morishita A bunch of compaction tests started failing after some changes to how logs are handled in ccm: - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.compaction_throughput_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.data_size_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_alter_and_nodetool_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_alter_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_nodetool_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.disable_autocompaction_schema_test - compaction_test.TestCompaction_with_DateTieredCompactionStrategy.sstable_deletion_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.compaction_throughput_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.data_size_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_alter_and_nodetool_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_alter_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_nodetool_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.disable_autocompaction_schema_test - compaction_test.TestCompaction_with_LeveledCompactionStrategy.sstable_deletion_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.compaction_throughput_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.data_size_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_alter_and_nodetool_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_alter_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_nodetool_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.disable_autocompaction_schema_test - compaction_test.TestCompaction_with_SizeTieredCompactionStrategy.sstable_deletion_test I haven't dug into it much, but it looks like the following tests: - compaction_throughput_test - data_size_test - disable_autocompaction_alter_and_nodetool_test - disable_autocompaction_alter_test - disable_autocompaction_nodetool_test - disable_autocompaction_schema_test - sstable_deletion_test grep logs to check if operations happened successfully, and that something in the new log-handling code broke this. I'm assigning [~yukim], since I believe you wrote the changes to ccm, but feel free to find a new assignee. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10453) Fix compression_cql_options_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Witschey resolved CASSANDRA-10453. -- Resolution: Fixed > Fix compression_cql_options_test dtest > -- > > Key: CASSANDRA-10453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This has been failing hard for a while: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ > This regression, like CASSANDRA-10451, started when the recent log changes > were introduced: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes > I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] > again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10453) Fix compression_cql_options_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945986#comment-14945986 ] Jim Witschey commented on CASSANDRA-10453: -- Sorry to have bugged you on this -- it was already fixed in ccm and passes on CassCI now: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/226/testReport/junit/compression_test/TestCompression/compression_cql_options_test/ Closing. > Fix compression_cql_options_test dtest > -- > > Key: CASSANDRA-10453 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10453 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This has been failing hard for a while: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/testReport/junit/compression_test/TestCompression/compression_cql_options_test/history/ > This regression, like CASSANDRA-10451, started when the recent log changes > were introduced: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/206/changes > I also can't reproduce on OpenStack. Pinging [~pauloricardomg] and [~blerer] > again. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10456) fix deprecated_repair_test dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Witschey resolved CASSANDRA-10456. -- Resolution: Fixed > fix deprecated_repair_test dtests > - > > Key: CASSANDRA-10456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10456 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Jim Witschey > Fix For: 3.0.0 rc2 > > > All the deprecated_repair_test dtests are failing on CassCI. I believe the > immediate cause is some recent changes to logs and how ccm handles them, like > the failures in CASSANDRA-10451 and CASSANDRA-10453. Test failures on CassCI > here: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/deprecated_repair_test/ > I'm assigning myself to track this, in case there are other failures to deal > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10456) fix deprecated_repair_test dtests
[ https://issues.apache.org/jira/browse/CASSANDRA-10456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945987#comment-14945987 ] Jim Witschey commented on CASSANDRA-10456: -- Yes, this is fixed: http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/226/testReport/deprecated_repair_test/ Closing. > fix deprecated_repair_test dtests > - > > Key: CASSANDRA-10456 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10456 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Jim Witschey > Fix For: 3.0.0 rc2 > > > All the deprecated_repair_test dtests are failing on CassCI. I believe the > immediate cause is some recent changes to logs and how ccm handles them, like > the failures in CASSANDRA-10451 and CASSANDRA-10453. Test failures on CassCI > here: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/deprecated_repair_test/ > I'm assigning myself to track this, in case there are other failures to deal > with. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10455) Fix pep8 compliance in cqlsh.py
[ https://issues.apache.org/jira/browse/CASSANDRA-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14946010#comment-14946010 ] Stefania commented on CASSANDRA-10455: -- +1 > Fix pep8 compliance in cqlsh.py > --- > > Key: CASSANDRA-10455 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10455 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Philip Thompson > Labels: cqlsh > Fix For: 3.0.0 rc2 > > > cqlsh has fallen out of pep8 compliance: > http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/cqlsh_tests.cqlsh_tests/TestCqlsh/test_pep8_compliance/ > [~philipthompson] has said off-JIRA that he'll fix it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10461) Fix sstableverify_test dtest
[ https://issues.apache.org/jira/browse/CASSANDRA-10461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Witschey updated CASSANDRA-10461: - Assignee: Sylvain Lebresne > Fix sstableverify_test dtest > > > Key: CASSANDRA-10461 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10461 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Sylvain Lebresne > Fix For: 3.0.0 rc2 > > > The dtest for sstableverify is failing: > http://cassci.datastax.com/view/cassandra-3.0/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/offline_tools_test/TestOfflineTools/sstableverify_test/ > It fails in the same way when I run it on OpenStack, so I don't think it's > just a CassCI problem. > [~slebresne] Looks like you made changes to this test recently: > https://github.com/riptano/cassandra-dtest/commit/51ab085f21e01cc8e5ad88a277cb4a43abd3f880 > Could you have a look at the failure? I'm assigning you for triage, but feel > free to reassign. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945982#comment-14945982
]
Jim Witschey commented on CASSANDRA-10451:
--
Fixed by the changes to ccm:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_single_table_test/history/
Closing.
> Fix
> batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
> on CassCI
> --
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Witschey resolved CASSANDRA-10451.
--
Resolution: Fixed
> Fix
> batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
> on CassCI
> --
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10449) OOM on bootstrap due to long GC pause
[
https://issues.apache.org/jira/browse/CASSANDRA-10449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Strickland updated CASSANDRA-10449:
--
Attachment: system.log.10-05
> OOM on bootstrap due to long GC pause
> -
>
> Key: CASSANDRA-10449
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10449
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Ubuntu 14.04, AWS
>Reporter: Robbie Strickland
> Labels: gc
> Fix For: 2.1.x
>
> Attachments: system.log.10-05
>
>
> I have a 20-node cluster (i2.4xlarge) with vnodes (default of 256) and
> 500-700GB per node. SSTable counts are <10 per table. I am attempting to
> provision additional nodes, but bootstrapping OOMs every time after about 10
> hours with a sudden long GC pause:
> {noformat}
> INFO [Service Thread] 2015-10-05 23:33:33,373 GCInspector.java:252 - G1 Old
> Generation GC in 1586126ms. G1 Old Gen: 49213756976 -> 49072277176;
> ...
> ERROR [MemtableFlushWriter:454] 2015-10-05 23:33:33,380
> CassandraDaemon.java:223 - Exception in thread
> Thread[MemtableFlushWriter:454,5,main]
> java.lang.OutOfMemoryError: Java heap space
> {noformat}
> I have tried increasing max heap to 48G just to get through the bootstrap, to
> no avail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10448) "Unknown type 0" Stream failure on Repair
[
https://issues.apache.org/jira/browse/CASSANDRA-10448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945077#comment-14945077
]
Yuki Morishita commented on CASSANDRA-10448:
This looks like network error.
We are working on to introduce auto reconnect in the future (CASSANDRA-8621).
> "Unknown type 0" Stream failure on Repair
> -
>
> Key: CASSANDRA-10448
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10448
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.2
> 5 Nodes in Google Compute Engine
> Java 1.8.0_60
>Reporter: Omri Iluz
>Assignee: Yuki Morishita
> Fix For: 2.2.x
>
>
> While running repair after upgrading to 2.2.2 I am getting many stream fail
> errors:
> {noformat}
> [2015-10-05 23:52:30,353] Repair session 4c181051-6bbb-11e5-acdb-d9a8bbd39330
> for range (59694553044959221,86389982480621619] failed with error [repair
> #4c181051-6bbb-11e5-acdb-d9a8bbd39330 on px/acti
> vities, (59694553044959221,86389982480621619]] Sync failed between
> /10.240.81.104 and /10.240.134.221 (progress: 4%)
> {noformat}
> Logs from both sides of the stream:
> Sides 1 -
> {noformat}
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:111 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Creating new streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52722] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-INIT-/10.240.81.104:52723] 2015-10-05 23:52:30,063
> StreamResultFuture.java:118 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Received streaming plan for Repair
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 13 files(517391317 bytes), sending 10
> files(469491729 bytes)
> ERROR [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,234
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> java.lang.IllegalArgumentException: Unknown type 0
> at
> org.apache.cassandra.streaming.messages.StreamMessage$Type.get(StreamMessage.java:96)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.messages.StreamMessage.deserialize(StreamMessage.java:57)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.ConnectionHandler$IncomingMessageHandler.run(ConnectionHandler.java:261)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_60]
> INFO [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.81.104 is complete
> WARN [STREAM-IN-/10.240.81.104] 2015-10-05 23:52:30,302
> StreamResultFuture.java:209 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Stream failed
> {noformat}
> Side 2 -
> {noformat}
> INFO [AntiEntropyStage:1] 2015-10-05 23:52:30,060 StreamResultFuture.java:86
> - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550] Executing streaming plan for
> Repair
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,061
> StreamSession.java:232 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Starting streaming to /10.240.134.221
> INFO [StreamConnectionEstablisher:6] 2015-10-05 23:52:30,063
> StreamCoordinator.java:213 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550,
> ID#0] Beginning stream session with /10.240.134.221
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,098
> StreamResultFuture.java:168 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550
> ID#0] Prepare completed. Receiving 10 files(469491729 bytes), sending 13
> files(517391317 bytes)
> INFO [STREAM-IN-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamResultFuture.java:182 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Session with /10.240.134.221 is complete
> ERROR [STREAM-OUT-/10.240.134.221] 2015-10-05 23:52:30,349
> StreamSession.java:524 - [Stream #239d8e60-6bbc-11e5-93ac-31bdef2dc550]
> Streaming error occurred
> org.apache.cassandra.io.FSReadError: java.io.IOException: Broken pipe
> at
> org.apache.cassandra.io.util.ChannelProxy.transferTo(ChannelProxy.java:144)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:79)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
> org.apache.cassandra.streaming.compress.CompressedStreamWriter$1.apply(CompressedStreamWriter.java:76)
> ~[apache-cassandra-2.2.2.jar:2.2.2]
> at
>
[jira] [Assigned] (CASSANDRA-10413) Replaying materialized view updates from commitlog after node decommission crashes Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Knighton reassigned CASSANDRA-10413:
-
Assignee: Joel Knighton (was: T Jake Luciani)
> Replaying materialized view updates from commitlog after node decommission
> crashes Cassandra
>
>
> Key: CASSANDRA-10413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 3.0.0 rc2
>
> Attachments: n1.log, n2.log, n3.log, n4.log, n5.log
>
>
> This issue is reproducible through a Jepsen test, runnable as
> {code}
> lein with-profile +trunk test :only
> cassandra.mv-test/mv-crash-subset-decommission
> {code}
> This test crashes/restarts nodes while decommissioning nodes. These actions
> are not coordinated.
> In [10164|https://issues.apache.org/jira/browse/CASSANDRA-10164], we
> introduced a change to re-apply materialized view updates on commitlog replay.
> Some nodes, upon restart, will crash in commitlog replay. They throw the
> "Trying to get the view natural endpoint on a non-data replica" runtime
> exception in getViewNaturalEndpoint. I added logging to
> getViewNaturalEndpoint to show the results of
> replicationStrategy.getNaturalEndpoints for the baseToken and viewToken.
> It can be seen that these problems occur when the baseEndpoints and
> viewEndpoints are identical but do not contain the broadcast address of the
> local node.
> For example, a node at 10.0.0.5 crashes on replay of a write whose base token
> and view token replicas are both [10.0.0.2, 10.0.0.4, 10.0.0.6]. It seems we
> try to guard against this by considering pendingEndpoints for the viewToken,
> but this does not appear to be sufficient.
> I've attached the system.logs for a test run with added logging. In the
> attached logs, n1 is at 10.0.0.2, n2 is at 10.0.0.3, and so on. 10.0.0.6/n5
> is the decommissioned node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10443) CQLSStableWriter example fails on 3.0rc1
[ https://issues.apache.org/jira/browse/CASSANDRA-10443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuki Morishita updated CASSANDRA-10443: --- Reviewer: Yuki Morishita > CQLSStableWriter example fails on 3.0rc1 > > > Key: CASSANDRA-10443 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10443 > Project: Cassandra > Issue Type: Bug > Components: Core, Tools >Reporter: Jonathan Shook >Assignee: Carl Yeksigian > Fix For: 3.0.0 rc2 > > > CQLSSTableWriter which works with 2.2.1 does not work with 3.0rc1. > Something like https://github.com/yukim/cassandra-bulkload-example should be > added to the test suite. > Exception in thread "main" java.lang.RuntimeException: > java.lang.ExceptionInInitializerError > at > org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter.close(SSTableSimpleUnsortedWriter.java:136) > at > org.apache.cassandra.io.sstable.CQLSSTableWriter.close(CQLSSTableWriter.java:274) > at com.metawiring.sandbox.BulkLoadExample.main(BulkLoadExample.java:160) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140) > Caused by: java.lang.ExceptionInInitializerError > at org.apache.cassandra.db.Keyspace.initCf(Keyspace.java:372) > at org.apache.cassandra.db.Keyspace.(Keyspace.java:309) > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:133) > at org.apache.cassandra.db.Keyspace.open(Keyspace.java:110) > at > org.apache.cassandra.io.sstable.SSTableTxnWriter.create(SSTableTxnWriter.java:97) > at > org.apache.cassandra.io.sstable.AbstractSSTableSimpleWriter.createWriter(AbstractSSTableSimpleWriter.java:63) > at > org.apache.cassandra.io.sstable.SSTableSimpleUnsortedWriter$DiskWriter.run(SSTableSimpleUnsortedWriter.java:206) > Caused by: java.lang.NullPointerException > at > org.apache.cassandra.config.DatabaseDescriptor.getFlushWriters(DatabaseDescriptor.java:1153) > at > org.apache.cassandra.db.ColumnFamilyStore.(ColumnFamilyStore.java:116) > ... 7 more -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10365) Consider storing types by their CQL names in schema tables instead of fully-qualified internal class names
[ https://issues.apache.org/jira/browse/CASSANDRA-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945353#comment-14945353 ] Bulat Shakirzyanov commented on CASSANDRA-10365: I think this is a very useful metadata to include. My only suggestion is to keep the old representation (fqcn) as well. Currently drivers use this representation to detect type information. Parsing CQL-only representation might not be robust for the reasons mentioned in https://issues.apache.org/jira/browse/CASSANDRA-6717#comment-14791788. > Consider storing types by their CQL names in schema tables instead of > fully-qualified internal class names > -- > > Key: CASSANDRA-10365 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10365 > Project: Cassandra > Issue Type: Improvement >Reporter: Aleksey Yeschenko >Assignee: Aleksey Yeschenko > Labels: client-impacting > Fix For: 3.0.0 rc2 > > > Consider saving CQL types names for column, UDF/UDA arguments and return > types, and UDT components. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10413) Replaying materialized view updates from commitlog after node decommission crashes Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10413:
Reviewer: Joel Knighton
> Replaying materialized view updates from commitlog after node decommission
> crashes Cassandra
>
>
> Key: CASSANDRA-10413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: T Jake Luciani
>Priority: Critical
> Fix For: 3.0.0 rc2
>
> Attachments: n1.log, n2.log, n3.log, n4.log, n5.log
>
>
> This issue is reproducible through a Jepsen test, runnable as
> {code}
> lein with-profile +trunk test :only
> cassandra.mv-test/mv-crash-subset-decommission
> {code}
> This test crashes/restarts nodes while decommissioning nodes. These actions
> are not coordinated.
> In [10164|https://issues.apache.org/jira/browse/CASSANDRA-10164], we
> introduced a change to re-apply materialized view updates on commitlog replay.
> Some nodes, upon restart, will crash in commitlog replay. They throw the
> "Trying to get the view natural endpoint on a non-data replica" runtime
> exception in getViewNaturalEndpoint. I added logging to
> getViewNaturalEndpoint to show the results of
> replicationStrategy.getNaturalEndpoints for the baseToken and viewToken.
> It can be seen that these problems occur when the baseEndpoints and
> viewEndpoints are identical but do not contain the broadcast address of the
> local node.
> For example, a node at 10.0.0.5 crashes on replay of a write whose base token
> and view token replicas are both [10.0.0.2, 10.0.0.4, 10.0.0.6]. It seems we
> try to guard against this by considering pendingEndpoints for the viewToken,
> but this does not appear to be sufficient.
> I've attached the system.logs for a test run with added logging. In the
> attached logs, n1 is at 10.0.0.2, n2 is at 10.0.0.3, and so on. 10.0.0.6/n5
> is the decommissioned node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10413) Replaying materialized view updates from commitlog after node decommission crashes Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Knighton updated CASSANDRA-10413:
--
Reviewer: (was: Joel Knighton)
> Replaying materialized view updates from commitlog after node decommission
> crashes Cassandra
>
>
> Key: CASSANDRA-10413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 3.0.0 rc2
>
> Attachments: n1.log, n2.log, n3.log, n4.log, n5.log
>
>
> This issue is reproducible through a Jepsen test, runnable as
> {code}
> lein with-profile +trunk test :only
> cassandra.mv-test/mv-crash-subset-decommission
> {code}
> This test crashes/restarts nodes while decommissioning nodes. These actions
> are not coordinated.
> In [10164|https://issues.apache.org/jira/browse/CASSANDRA-10164], we
> introduced a change to re-apply materialized view updates on commitlog replay.
> Some nodes, upon restart, will crash in commitlog replay. They throw the
> "Trying to get the view natural endpoint on a non-data replica" runtime
> exception in getViewNaturalEndpoint. I added logging to
> getViewNaturalEndpoint to show the results of
> replicationStrategy.getNaturalEndpoints for the baseToken and viewToken.
> It can be seen that these problems occur when the baseEndpoints and
> viewEndpoints are identical but do not contain the broadcast address of the
> local node.
> For example, a node at 10.0.0.5 crashes on replay of a write whose base token
> and view token replicas are both [10.0.0.2, 10.0.0.4, 10.0.0.6]. It seems we
> try to guard against this by considering pendingEndpoints for the viewToken,
> but this does not appear to be sufficient.
> I've attached the system.logs for a test run with added logging. In the
> attached logs, n1 is at 10.0.0.2, n2 is at 10.0.0.3, and so on. 10.0.0.6/n5
> is the decommissioned node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10413) Replaying materialized view updates from commitlog after node decommission crashes Cassandra
[
https://issues.apache.org/jira/browse/CASSANDRA-10413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joel Knighton updated CASSANDRA-10413:
--
Reviewer: T Jake Luciani
> Replaying materialized view updates from commitlog after node decommission
> crashes Cassandra
>
>
> Key: CASSANDRA-10413
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10413
> Project: Cassandra
> Issue Type: Bug
>Reporter: Joel Knighton
>Assignee: Joel Knighton
>Priority: Critical
> Fix For: 3.0.0 rc2
>
> Attachments: n1.log, n2.log, n3.log, n4.log, n5.log
>
>
> This issue is reproducible through a Jepsen test, runnable as
> {code}
> lein with-profile +trunk test :only
> cassandra.mv-test/mv-crash-subset-decommission
> {code}
> This test crashes/restarts nodes while decommissioning nodes. These actions
> are not coordinated.
> In [10164|https://issues.apache.org/jira/browse/CASSANDRA-10164], we
> introduced a change to re-apply materialized view updates on commitlog replay.
> Some nodes, upon restart, will crash in commitlog replay. They throw the
> "Trying to get the view natural endpoint on a non-data replica" runtime
> exception in getViewNaturalEndpoint. I added logging to
> getViewNaturalEndpoint to show the results of
> replicationStrategy.getNaturalEndpoints for the baseToken and viewToken.
> It can be seen that these problems occur when the baseEndpoints and
> viewEndpoints are identical but do not contain the broadcast address of the
> local node.
> For example, a node at 10.0.0.5 crashes on replay of a write whose base token
> and view token replicas are both [10.0.0.2, 10.0.0.4, 10.0.0.6]. It seems we
> try to guard against this by considering pendingEndpoints for the viewToken,
> but this does not appear to be sufficient.
> I've attached the system.logs for a test run with added logging. In the
> attached logs, n1 is at 10.0.0.2, n2 is at 10.0.0.3, and so on. 10.0.0.6/n5
> is the decommissioned node.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10447) Async logging configuration doesn't result in data flushing when shutdown hook runs
[ https://issues.apache.org/jira/browse/CASSANDRA-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945348#comment-14945348 ] Ariel Weisberg commented on CASSANDRA-10447: Oh thanks Paulo, I didn't have the source for logbook classic loaded so I didn't see that LoggerContext overrides stop(). I was very confused. It's easy to reproduce. On trunk run "ant test -Dtest.name=RoleOptionsTest" and then look at the log file in build/test/logs. For me the log file is empty. It definitely happens in the test config and it's very obvious. Whether it happens in the production config is harder to suss out since the production config doesn't buffer heavily like the test config and drains as fast as it can. My suspicion is that it should have the same issue not stopping appenders. If you are free you are welcome to look at it. I am doing two code reviews, but I should be able to get to both for 3.0.0rc2. > Async logging configuration doesn't result in data flushing when shutdown > hook runs > --- > > Key: CASSANDRA-10447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10447 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Fix For: 3.0.0 rc2 > > > Stefania discovered that tests that don't produce a lot of log output end up > producing 0 debug output to files because the data is not flushed as part of > the shutdown hook. I traced through and it looks like the shutdown hook > doesn't actually invoke code that does anything useful. It shuts down an > executor service in the logging context but doesn't call stop on any > appenders. > A hackish thing we can do is use a status listener to collect all the > appenders and then stop them when the shutdown hook runs. Even adding a small > delay to the shutdown hook (no code changes on our part) would in let the > async appender flush in 90% of cases. > We still need to fix it for test which uses a different config file and for > which a small delay is not desirable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10452) Fix flapping resummable_bootstrap_test
Jim Witschey created CASSANDRA-10452:
Summary: Fix flapping resummable_bootstrap_test
Key: CASSANDRA-10452
URL: https://issues.apache.org/jira/browse/CASSANDRA-10452
Project: Cassandra
Issue Type: Sub-task
Reporter: Jim Witschey
Assignee: Yuki Morishita
Fix For: 3.0.0 rc2
{{bootstrap_test.py:TestBootstrap.resumable_bootstrap_test}} has been flapping
on CassCI lately:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/bootstrap_test/TestBootstrap/resumable_bootstrap_test/history/
I have not been able to reproduce on OpenStack. I'm assigning [~yukim] for now,
but feel free to reassign.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10412) Could not initialize class org.apache.cassandra.config.DatabaseDescriptor
[ https://issues.apache.org/jira/browse/CASSANDRA-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carl Yeksigian updated CASSANDRA-10412: --- Fix Version/s: 2.2.x > Could not initialize class org.apache.cassandra.config.DatabaseDescriptor > - > > Key: CASSANDRA-10412 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10412 > Project: Cassandra > Issue Type: Bug > Components: Core > Environment: OS: Windows 2012 R2 > Java JRE: 1.8.0_51 >Reporter: Eric Simmons >Assignee: Carl Yeksigian >Priority: Minor > Fix For: 2.2.x > > Attachments: cassandra-env.ps1, cassandra.yaml > > > We are unable to start version 2.2.1 on our Windows 2012 R2 systems, however > we can use the same environment to start version 2.1.2 > I have attached our Cassandra.yaml and cassandra-env.ps1 file for reference. > I have also attached the system.log file displaying the error. > I have also included an excerpt of the log file showing the stack trace of > the error. > ERROR [ScheduledTasks:1] 2015-09-29 07:03:47,482 > DebuggableThreadPoolExecutor.java:242 - Error in ThreadPoolExecutor > java.lang.NoClassDefFoundError: Could not initialize class > org.apache.cassandra.config.DatabaseDescriptor > at > org.apache.cassandra.utils.JVMStabilityInspector.inspectThrowable(JVMStabilityInspector.java:57) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at > org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:122) > ~[apache-cassandra-2.2.1.jar:2.2.1] > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > ~[na:1.8.0_51] > at java.util.concurrent.FutureTask.runAndReset(Unknown Source) > ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown > Source) ~[na:1.8.0_51] > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown > Source) ~[na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > [na:1.8.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > [na:1.8.0_51] > at java.lang.Thread.run(Unknown Source) [na:1.8.0_51] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10447) Async logging configuration doesn't result in data flushing when shutdown hook runs
[
https://issues.apache.org/jira/browse/CASSANDRA-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945255#comment-14945255
]
Paulo Motta commented on CASSANDRA-10447:
-
The shutdown hook seems to be implemented correctly on
[DelayingShutdownHook|https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/hook/DelayingShutdownHook.java],
that calls {{ContextBase.stop()}}. Even though the
[ContextBase|https://github.com/qos-ch/logback/blob/master/logback-core/src/main/java/ch/qos/logback/core/ContextBase.java]
{{stop()}} implementation only shutdowns an executor service, it seems the
[LoggerContext|https://github.com/qos-ch/logback/blob/master/logback-classic/src/main/java/ch/qos/logback/classic/LoggerContext.java],
which overrides {{ContextBase.stop()}}, closes all appenders when invoked by
{{DelayingShutdownHook}}.
In what situations is the problem occurring, is there an easy way to reproduce?
Maybe shutdown hooks are never triggered during unit tests? We need first to
clarify if this is specific to the test configuration or if it also happens in
the production configuration too. I'm happy to review and help with this.
> Async logging configuration doesn't result in data flushing when shutdown
> hook runs
> ---
>
> Key: CASSANDRA-10447
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10447
> Project: Cassandra
> Issue Type: Bug
>Reporter: Ariel Weisberg
>Assignee: Ariel Weisberg
> Fix For: 3.0.0 rc2
>
>
> Stefania discovered that tests that don't produce a lot of log output end up
> producing 0 debug output to files because the data is not flushed as part of
> the shutdown hook. I traced through and it looks like the shutdown hook
> doesn't actually invoke code that does anything useful. It shuts down an
> executor service in the logging context but doesn't call stop on any
> appenders.
> A hackish thing we can do is use a status listener to collect all the
> appenders and then stop them when the shutdown hook runs. Even adding a small
> delay to the shutdown hook (no code changes on our part) would in let the
> async appender flush in 90% of cases.
> We still need to fix it for test which uses a different config file and for
> which a small delay is not desirable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Witschey updated CASSANDRA-10205:
-
Fix Version/s: 3.0.0 rc2
> decommissioned_wiped_node_can_join_test fails on Jenkins
>
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622)
> [main/:na]
> WARN [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I
> don't think the problem is the Amazon private addresses but I might be wrong.
> It's also worth noting that the first time the node starts up without
> problems. The problem only occurs during a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10205) decommissioned_wiped_node_can_join_test fails on Jenkins
[
https://issues.apache.org/jira/browse/CASSANDRA-10205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Witschey updated CASSANDRA-10205:
-
Issue Type: Sub-task (was: Test)
Parent: CASSANDRA-10166
> decommissioned_wiped_node_can_join_test fails on Jenkins
>
>
> Key: CASSANDRA-10205
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10205
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Stefania
>Assignee: Stefania
> Fix For: 3.0.0 rc2
>
> Attachments: decommissioned_wiped_node_can_join_test.tar.gz
>
>
> This test passes locally but reliably fails on Jenkins. It seems after we
> restart node4, it is unable to Gossip with other nodes:
> {code}
> INFO [HANDSHAKE-/127.0.0.2] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.2
> INFO [HANDSHAKE-/127.0.0.1] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.1
> INFO [HANDSHAKE-/127.0.0.3] 2015-08-27 06:50:42,778
> OutboundTcpConnection.java:494 - Handshaking version with /127.0.0.3
> ERROR [main] 2015-08-27 06:51:13,785 CassandraDaemon.java:635 - Exception
> encountered during startup
> java.lang.RuntimeException: Unable to gossip with any seeds
> at
> org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1342)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.checkForEndpointCollision(StorageService.java:518)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.prepareToJoin(StorageService.java:763)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:687)
> ~[main/:na]
> at
> org.apache.cassandra.service.StorageService.initServer(StorageService.java:570)
> ~[main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:320)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:516)
> [main/:na]
> at
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622)
> [main/:na]
> WARN [StorageServiceShutdownHook] 2015-08-27 06:51:13,799 Gossiper.java:1453
> - No local state or state is in silent shutdown, not announcing shutdown
> {code}
> It seems both the addresses and port number of the seeds are correct so I
> don't think the problem is the Amazon private addresses but I might be wrong.
> It's also worth noting that the first time the node starts up without
> problems. The problem only occurs during a restart.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945325#comment-14945325
]
Jim Witschey commented on CASSANDRA-10451:
--
Sorry, I was looking at trunk instead of the 3.0 tests. However, the same
pattern of failures shows up on the cassandra-3.0 branch:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
The same pattern also shows on the
{{logged_batch_gcgs_below_threshold_single_table_test}} tests:
http://cassci.datastax.com/view/trunk/job/cassandra-3.0_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_single_table_test/history/
I'll edit the title to reflect that.
> Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test
> on CassCI
> -
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10447) Async logging configuration doesn't result in data flushing when shutdown hook runs
[ https://issues.apache.org/jira/browse/CASSANDRA-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta updated CASSANDRA-10447: Reviewer: Paulo Motta > Async logging configuration doesn't result in data flushing when shutdown > hook runs > --- > > Key: CASSANDRA-10447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10447 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Fix For: 3.0.0 rc2 > > > Stefania discovered that tests that don't produce a lot of log output end up > producing 0 debug output to files because the data is not flushed as part of > the shutdown hook. I traced through and it looks like the shutdown hook > doesn't actually invoke code that does anything useful. It shuts down an > executor service in the logging context but doesn't call stop on any > appenders. > A hackish thing we can do is use a status listener to collect all the > appenders and then stop them when the shutdown hook runs. Even adding a small > delay to the shutdown hook (no code changes on our part) would in let the > async appender flush in 90% of cases. > We still need to fix it for test which uses a different config file and for > which a small delay is not desirable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CASSANDRA-10450) upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions flapped on CassCI
Jim Witschey created CASSANDRA-10450: Summary: upgrade_tests/paging_test.py:TestPagingWithDeletions.test_single_cell_deletions flapped on CassCI Key: CASSANDRA-10450 URL: https://issues.apache.org/jira/browse/CASSANDRA-10450 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Priority: Minor Fix For: 3.0.0 rc2 This test has failed with a single flap: http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/upgrade_tests.paging_test/TestPagingWithDeletions/test_single_cell_deletions/history/ This may not be worth blocking release on; I haven't been able to reproduce on openstack, and it's only flapped once. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10233) IndexOutOfBoundsException in HintedHandOffManager
[
https://issues.apache.org/jira/browse/CASSANDRA-10233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joshua McKenzie updated CASSANDRA-10233:
Assignee: J.P. Eiti Kimura (was: Paulo Motta)
> IndexOutOfBoundsException in HintedHandOffManager
> -
>
> Key: CASSANDRA-10233
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10233
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Environment: Cassandra 2.2.0
>Reporter: Omri Iluz
>Assignee: J.P. Eiti Kimura
> Attachments: cassandra-2.1.8-10233-v2.txt,
> cassandra-2.1.8-10233-v3.txt, cassandra-2.1.8-10233-v4.txt,
> cassandra-2.2.1-10233.txt
>
>
> After upgrading our cluster to 2.2.0, the following error started showing
> exectly every 10 minutes on every server in the cluster:
> {noformat}
> INFO [CompactionExecutor:1381] 2015-08-31 18:31:55,506
> CompactionTask.java:142 - Compacting (8e7e1520-500e-11e5-b1e3-e95897ba4d20)
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-540-big-Data.db:level=0,
> ]
> INFO [CompactionExecutor:1381] 2015-08-31 18:31:55,599
> CompactionTask.java:224 - Compacted (8e7e1520-500e-11e5-b1e3-e95897ba4d20) 1
> sstables to
> [/cassandra/data/system/hints-2666e20573ef38b390fefecf96e8f0c7/la-541-big,]
> to level=0. 1,544,495 bytes to 1,544,495 (~100% of original) in 93ms =
> 15.838121MB/s. 0 total partitions merged to 4. Partition merge counts were
> {1:4, }
> ERROR [HintedHandoff:1] 2015-08-31 18:31:55,600 CassandraDaemon.java:182 -
> Exception in thread Thread[HintedHandoff:1,1,main]
> java.lang.IndexOutOfBoundsException: null
> at java.nio.Buffer.checkIndex(Buffer.java:538) ~[na:1.7.0_79]
> at java.nio.HeapByteBuffer.getLong(HeapByteBuffer.java:410)
> ~[na:1.7.0_79]
> at org.apache.cassandra.utils.UUIDGen.getUUID(UUIDGen.java:106)
> ~[apache-cassandra-2.2.0.jar:2.2.0]
> at
> org.apache.cassandra.db.HintedHandOffManager.scheduleAllDeliveries(HintedHandOffManager.java:515)
> ~[apache-cassandra-2.2.0.jar:2.2.0]
> at
> org.apache.cassandra.db.HintedHandOffManager.access$000(HintedHandOffManager.java:88)
> ~[apache-cassandra-2.2.0.jar:2.2.0]
> at
> org.apache.cassandra.db.HintedHandOffManager$1.run(HintedHandOffManager.java:168)
> ~[apache-cassandra-2.2.0.jar:2.2.0]
> at
> org.apache.cassandra.concurrent.DebuggableScheduledThreadPoolExecutor$UncomplainingRunnable.run(DebuggableScheduledThreadPoolExecutor.java:118)
> ~[apache-cassandra-2.2.0.jar:2.2.0]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> [na:1.7.0_79]
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [na:1.7.0_79]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test on CassCI
Jim Witschey created CASSANDRA-10451: Summary: Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test on CassCI Key: CASSANDRA-10451 URL: https://issues.apache.org/jira/browse/CASSANDRA-10451 Project: Cassandra Issue Type: Sub-task Reporter: Jim Witschey Fix For: 3.0.0 rc2 This is a recent regression: http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/ Based on [when it started failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes], it looks like the regression was introduced by [the recent logging changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa]. Pinging [~blerer] and [~pauloricardomg] to have a look. My initial guess was that the logs the test depends on were moved to the new debug log. However, the tests passes when I run it manually on openstack, so it could just be a configuration issue on CassCI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10444) Create an option to forcibly disable tracing
[ https://issues.apache.org/jira/browse/CASSANDRA-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joshua McKenzie updated CASSANDRA-10444: Assignee: (was: Joshua McKenzie) > Create an option to forcibly disable tracing > > > Key: CASSANDRA-10444 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10444 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Brandon Williams >Priority: Minor > Fix For: 2.1.x > > > Sometimes people will experience dropped TRACE messages. Ostensibly, trace > is disabled on the server and we know it's from some client, somewhere. With > an inability to locate exactly where client code is causing this, it would be > useful to just be able to kill it entirely on the server side. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test on CassCI
[ https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paulo Motta reassigned CASSANDRA-10451: --- Assignee: Paulo Motta > Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test > on CassCI > - > > Key: CASSANDRA-10451 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10451 > Project: Cassandra > Issue Type: Sub-task >Reporter: Jim Witschey >Assignee: Paulo Motta > Fix For: 3.0.0 rc2 > > > This is a recent regression: > http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/ > Based on [when it started > failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes], > it looks like the regression was introduced by [the recent logging > changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa]. > Pinging [~blerer] and [~pauloricardomg] to have a look. > My initial guess was that the logs the test depends on were moved to the new > debug log. However, the tests passes when I run it manually on openstack, so > it could just be a configuration issue on CassCI. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CASSANDRA-10451) Fix batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test on CassCI
[
https://issues.apache.org/jira/browse/CASSANDRA-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Witschey updated CASSANDRA-10451:
-
Summary: Fix
batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
on CassCI (was: Fix
batch_test.TestBatch.logged_batch_gcgs_below_threshold_multi_table_test on
CassCI)
> Fix
> batch_test.TestBatch.logged_batch_gcgs_below_threshold_{multi,single}_table_test
> on CassCI
> --
>
> Key: CASSANDRA-10451
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10451
> Project: Cassandra
> Issue Type: Sub-task
>Reporter: Jim Witschey
>Assignee: Paulo Motta
> Fix For: 3.0.0 rc2
>
>
> This is a recent regression:
> http://cassci.datastax.com/view/trunk/job/trunk_dtest/lastCompletedBuild/testReport/batch_test/TestBatch/logged_batch_gcgs_below_threshold_multi_table_test/history/
> Based on [when it started
> failing|http://cassci.datastax.com/view/trunk/job/trunk_dtest/623/changes],
> it looks like the regression was introduced by [the recent logging
> changes|https://github.com/apache/cassandra/commit/4a849efeb7c7c1a54bc12094d2d6a9f3f008a2fa].
> Pinging [~blerer] and [~pauloricardomg] to have a look.
> My initial guess was that the logs the test depends on were moved to the new
> debug log. However, the tests passes when I run it manually on openstack, so
> it could just be a configuration issue on CassCI.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-7392) Abort in-progress queries that time out
[ https://issues.apache.org/jira/browse/CASSANDRA-7392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945386#comment-14945386 ] Ariel Weisberg commented on CASSANDRA-7392: --- +1 on the code. I can't really tell what test-all on trunk is doing. The last build timed out and the build before that did something weird. dtests look like dtests. test-all on 3.0 looked OK to me. > Abort in-progress queries that time out > --- > > Key: CASSANDRA-7392 > URL: https://issues.apache.org/jira/browse/CASSANDRA-7392 > Project: Cassandra > Issue Type: New Feature > Components: Core >Reporter: Jonathan Ellis >Assignee: Stefania >Priority: Critical > Fix For: 3.x > > > Currently we drop queries that time out before we get to them (because node > is overloaded) but not queries that time out while being processed. > (Particularly common for index queries on data that shouldn't be indexed.) > Adding the latter and logging when we have to interrupt one gets us a poor > man's "slow query log" for free. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-10437) Remove offheap_objects option until 9472 re-introduces them
[
https://issues.apache.org/jira/browse/CASSANDRA-10437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945432#comment-14945432
]
Ariel Weisberg commented on CASSANDRA-10437:
The code changes look fine, but is there a branch where this is being tested by
cassci? Are there dtests requesting this option?
> Remove offheap_objects option until 9472 re-introduces them
> ---
>
> Key: CASSANDRA-10437
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10437
> Project: Cassandra
> Issue Type: Bug
>Reporter: Sylvain Lebresne
>Assignee: Sylvain Lebresne
>Priority: Trivial
> Fix For: 3.0.0 rc2
>
> Attachments: 0001-Remove-offheap_objects-option.txt
>
>
> We need to send a meaningful error message if user try to use
> {{offheap_objects}} in 3.0 since it's not supported currently (pending
> CASSANDRA-9472). And document the current removal in the NEWS file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9126) java.lang.RuntimeException: Last written key DecoratedKey >= current key DecoratedKey
[
https://issues.apache.org/jira/browse/CASSANDRA-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14945115#comment-14945115
]
Jim Witschey commented on CASSANDRA-9126:
-
[~krummas] Sure -- could we add that advice to the error messages these users
received? Or are these errors raised in too many situations for that to be
appropriate?
> java.lang.RuntimeException: Last written key DecoratedKey >= current key
> DecoratedKey
> -
>
> Key: CASSANDRA-9126
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9126
> Project: Cassandra
> Issue Type: Bug
> Components: Core
>Reporter: srinivasu gottipati
>Priority: Critical
> Fix For: 2.1.x
>
> Attachments: cassandra-system.log
>
>
> Cassandra V: 2.0.14,
> Getting the following exceptions while trying to compact (I see this issue
> was raised in earlier versions and marked as closed. However it still appears
> in 2.0.14). In our case, compaction is not getting succeeded and keep failing
> with this error.:
> {code}java.lang.RuntimeException: Last written key
> DecoratedKey(3462767860784856708,
> 354038323137333038305f3330325f31355f474d4543454f) >= current key
> DecoratedKey(3462334604624154281,
> 354036333036353334315f3336315f31355f474d4543454f) writing into {code}
> ...
> Stacktrace:{code}
> at
> org.apache.cassandra.io.sstable.SSTableWriter.beforeAppend(SSTableWriter.java:143)
> at
> org.apache.cassandra.io.sstable.SSTableWriter.append(SSTableWriter.java:166)
> at
> org.apache.cassandra.db.compaction.CompactionTask.runMayThrow(CompactionTask.java:167)
> at
> org.apache.cassandra.utils.WrappedRunnable.run(WrappedRunnable.java:28)
> at
> org.apache.cassandra.db.compaction.CompactionTask.executeInternal(CompactionTask.java:60)
> at
> org.apache.cassandra.db.compaction.AbstractCompactionTask.execute(AbstractCompactionTask.java:59)
> at
> org.apache.cassandra.db.compaction.CompactionManager$BackgroundCompactionTask.run(CompactionManager.java:198)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745){code}
> Any help is greatly appreciated
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CASSANDRA-10447) Async logging configuration doesn't result in data flushing when shutdown hook runs
[ https://issues.apache.org/jira/browse/CASSANDRA-10447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ariel Weisberg reassigned CASSANDRA-10447: -- Assignee: Ariel Weisberg > Async logging configuration doesn't result in data flushing when shutdown > hook runs > --- > > Key: CASSANDRA-10447 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10447 > Project: Cassandra > Issue Type: Bug >Reporter: Ariel Weisberg >Assignee: Ariel Weisberg > Fix For: 3.0.0 rc2 > > > Stefania discovered that tests that don't produce a lot of log output end up > producing 0 debug output to files because the data is not flushed as part of > the shutdown hook. I traced through and it looks like the shutdown hook > doesn't actually invoke code that does anything useful. It shuts down an > executor service in the logging context but doesn't call stop on any > appenders. > A hackish thing we can do is use a status listener to collect all the > appenders and then stop them when the shutdown hook runs. Even adding a small > delay to the shutdown hook (no code changes on our part) would in let the > async appender flush in 90% of cases. > We still need to fix it for test which uses a different config file and for > which a small delay is not desirable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
