[jira] [Commented] (CASSANDRA-12804) CQL docs table of contents links are broken

2019-05-07 Thread James Howe (JIRA) 


[ 
https://issues.apache.org/jira/browse/CASSANDRA-12804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16834591#comment-16834591
 ] 

James Howe commented on CASSANDRA-12804:


Same problem with the docs at 
[http://cassandra.apache.org/doc/old/CQL-3.0.html] which are linked from 
[http://cassandra.apache.org/doc/]

> CQL docs table of contents links are broken
> ---
>
> Key: CASSANDRA-12804
> URL: https://issues.apache.org/jira/browse/CASSANDRA-12804
> Project: Cassandra
>  Issue Type: Bug
>  Components: Legacy/Documentation and Website
>Reporter: Evan Prothro
>Priority: Low
>  Labels: lhf
>
> Example: Clicking on a link in the table of contents at 
> https://cassandra.apache.org/doc/cql3/CQL-3.0.html results in a 404 to 
> https://cassandra.apache.org/doc/cql3/CQL.html#Preamble
> This ticket proposes changing the paths of legacy CQL.html files so they 
> work, removing the textile source for this legacy doc (as it is replaced by 
> the in-tree sphinx docs now),  and updating the live docs to a sphinx build 
> from 3.9.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13888) Support GROUP BY on indexed columns

2017-09-20 Thread James Howe (JIRA) 
James Howe created CASSANDRA-13888:
--

 Summary: Support GROUP BY on indexed columns
 Key: CASSANDRA-13888
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13888
 Project: Cassandra
  Issue Type: New Feature
  Components: CQL
Reporter: James Howe






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13887) Add SASI metrics to JMX

2017-09-20 Thread James Howe (JIRA) 
James Howe created CASSANDRA-13887:
--

 Summary: Add SASI metrics to JMX
 Key: CASSANDRA-13887
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13887
 Project: Cassandra
  Issue Type: Improvement
  Components: sasi
Reporter: James Howe
Priority: Minor


Currently there are MBeans for secondary index metrics 
{{org.apache.cassandra.metrics:type=IndexTable}} but I cannot see SASI metrics 
anywhere.
The only place they're even mentioned is in the table's {{BuiltIndexes}} list.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

[jira] [Created] (CASSANDRA-13473) Missing quotes in cassandra-env.ps1

2017-04-25 Thread James Howe (JIRA) 
James Howe created CASSANDRA-13473:
--

 Summary: Missing quotes in cassandra-env.ps1
 Key: CASSANDRA-13473
 URL: https://issues.apache.org/jira/browse/CASSANDRA-13473
 Project: Cassandra
  Issue Type: Bug
  Components: Configuration
Reporter: James Howe
Priority: Minor


Cannot start Cassandra on Windows via Powershell if the configuration path 
contains spaces.

{noformat}
diff --git a/conf/cassandra-env.ps1 b/conf/cassandra-env.ps1
index 806eabc..c2765f8 100644
--- a/conf/cassandra-env.ps1
+++ b/conf/cassandra-env.ps1
@@ -376,9 +376,9 @@ Function SetCassandraEnvironment
 }
 }
 
-# provides hints to the JIT compiler
-$env:JVM_OPTS = "$env:JVM_OPTS 
-XX:CompileCommandFile=$env:CASSANDRA_CONF\hotspot_compiler"
-
+# provides hints to the JIT compiler
+$env:JVM_OPTS = "$env:JVM_OPTS 
-XX:CompileCommandFile=""$env:CASSANDRA_CONF\hotspot_compiler"""
+
 # add the jamm javaagent
 if (($env:JVM_VENDOR -ne "OpenJDK") -or 
($env:JVM_VERSION.CompareTo("1.6.0") -eq 1) -or
 (($env:JVM_VERSION -eq "1.6.0") -and 
($env:JVM_PATCH_VERSION.CompareTo("22") -eq 1)))
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (CASSANDRA-11995) Commitlog replaced with all NULs

2016-11-07 Thread James Howe (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Howe updated CASSANDRA-11995:
---
Description: 
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33,554,432 (32 * 1024 * 1024) 
NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.

  was:
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33,554,432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.


> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
>

[jira] [Commented] (CASSANDRA-11995) Commitlog replaced with all NULs

2016-09-29 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533075#comment-15533075
 ] 

James Howe commented on CASSANDRA-11995:


Just happened to me again.
[~jogarcia], are you also running on Windows?

> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
> [apache-cassandra-2.2.3.jar:2.2.3]
> {code}
> Checking the referenced file reveals it comprises 33,554,432 NUL bytes.
> No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
> appear exactly as normal.
> Is installed as a service via DataStax's distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (CASSANDRA-11995) Commitlog replaced with all NULs

2016-06-13 Thread James Howe (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Howe updated CASSANDRA-11995:
---
Description: 
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33,554,432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.

  was:
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33554432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.


> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
>

[jira] [Updated] (CASSANDRA-11995) Commitlog replaced with all NULs

2016-06-13 Thread James Howe (JIRA) 

 [ 
https://issues.apache.org/jira/browse/CASSANDRA-11995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Howe updated CASSANDRA-11995:
---
Description: 
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33554432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.
Is installed as a service via DataStax's distribution.

  was:
I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33554432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.


> Commitlog replaced with all NULs
> 
>
> Key: CASSANDRA-11995
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
> Project: Cassandra
>  Issue Type: Bug
>  Components: Core
> Environment: Windows 10 Enterprise 1511
> DataStax Cassandra Community Server 2.2.3
>Reporter: James Howe
>
> I noticed this morning that Cassandra was failing to start, after being shut 
> down on Friday.
> {code}
> ERROR 09:13:37 Exiting due to error while processing commit log during 
> initialization.
> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
> Could not read commit log descriptor in file C:\Program Files\DataStax 
> Community\data\commitlog\CommitLog-5-1465571056722.log
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
>  [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
> [apache-cassandra-2.2.3.jar:2.2.3]
>   at 
> org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
>

[jira] [Created] (CASSANDRA-11995) Commitlog replaced with all NULs

2016-06-13 Thread James Howe (JIRA) 
James Howe created CASSANDRA-11995:
--

 Summary: Commitlog replaced with all NULs
 Key: CASSANDRA-11995
 URL: https://issues.apache.org/jira/browse/CASSANDRA-11995
 Project: Cassandra
  Issue Type: Bug
  Components: Core
 Environment: Windows 10 Enterprise 1511
DataStax Cassandra Community Server 2.2.3
Reporter: James Howe


I noticed this morning that Cassandra was failing to start, after being shut 
down on Friday.
{code}
ERROR 09:13:37 Exiting due to error while processing commit log during 
initialization.
org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException: 
Could not read commit log descriptor in file C:\Program Files\DataStax 
Community\data\commitlog\CommitLog-5-1465571056722.log
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.handleReplayError(CommitLogReplayer.java:622)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:302)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLogReplayer.recover(CommitLogReplayer.java:147)
 [apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:189) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.db.commitlog.CommitLog.recover(CommitLog.java:169) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.java:273) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon.java:513) 
[apache-cassandra-2.2.3.jar:2.2.3]
at 
org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.java:622) 
[apache-cassandra-2.2.3.jar:2.2.3]
{code}
Checking the referenced file reveals it comprises 33554432 NUL bytes.
No logs (stdout, stderr, prunsrv) from the shutdown show any other issues and 
appear exactly as normal.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-10058) Close Java driver Client object in Hadoop and Pig classes

2016-04-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242791#comment-15242791
 ] 

James Howe edited comment on CASSANDRA-10058 at 4/15/16 11:09 AM:
--

Still seeing this LEAK message from the Datastax driver (2.1.9) using Cassandra 
2.2.4.
We're not running on Hadoop or Pig at all.
Does it require a driver upgrade too?


was (Author: jameshowe):
Still seeing this LEAK message from the Datastax driver (2.1.9) using Cassandra 
2.2.4.
Does it require a driver upgrade too?

> Close Java driver Client object in Hadoop and Pig classes
> -
>
> Key: CASSANDRA-10058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10058
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Alex Liu
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: CASSANDRA-10058-2.2.txt
>
>
> I found that some Hadoop and Pig code in Cassandra doesn't close the Client 
> object, that's the cause for the following errors in java driver 2.2.0-rc1.
> {code}
> ERROR 11:37:45 LEAK: You are creating too many HashedWheelTimer instances.  
> HashedWheelTimer is a shared resource that must be reused across the JVM,so 
> that only a few instances are created.
> {code}
> We should close the Client objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-10058) Close Java driver Client object in Hadoop and Pig classes

2016-04-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242791#comment-15242791
 ] 

James Howe edited comment on CASSANDRA-10058 at 4/15/16 11:07 AM:
--

Still seeing this LEAK message from the Datastax driver (2.1.9) using Cassandra 
2.2.4.
Does it require a driver upgrade too?


was (Author: jameshowe):
Still seeing this LEAK message from the Datastax driver (2.1.9) using Cassandra 
2.2.4.

> Close Java driver Client object in Hadoop and Pig classes
> -
>
> Key: CASSANDRA-10058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10058
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Alex Liu
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: CASSANDRA-10058-2.2.txt
>
>
> I found that some Hadoop and Pig code in Cassandra doesn't close the Client 
> object, that's the cause for the following errors in java driver 2.2.0-rc1.
> {code}
> ERROR 11:37:45 LEAK: You are creating too many HashedWheelTimer instances.  
> HashedWheelTimer is a shared resource that must be reused across the JVM,so 
> that only a few instances are created.
> {code}
> We should close the Client objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-10058) Close Java driver Client object in Hadoop and Pig classes

2016-04-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242791#comment-15242791
 ] 

James Howe edited comment on CASSANDRA-10058 at 4/15/16 10:48 AM:
--

Still seeing this LEAK message from the Datastax driver (2.1.9) using Cassandra 
2.2.4.


was (Author: jameshowe):
Still seeing this LEAK message using Cassandra 2.2.4 using Datastax driver 
2.1.9.

> Close Java driver Client object in Hadoop and Pig classes
> -
>
> Key: CASSANDRA-10058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10058
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Alex Liu
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: CASSANDRA-10058-2.2.txt
>
>
> I found that some Hadoop and Pig code in Cassandra doesn't close the Client 
> object, that's the cause for the following errors in java driver 2.2.0-rc1.
> {code}
> ERROR 11:37:45 LEAK: You are creating too many HashedWheelTimer instances.  
> HashedWheelTimer is a shared resource that must be reused across the JVM,so 
> that only a few instances are created.
> {code}
> We should close the Client objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-10058) Close Java driver Client object in Hadoop and Pig classes

2016-04-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242791#comment-15242791
 ] 

James Howe commented on CASSANDRA-10058:


Still seeing this LEAK message using Cassandra 2.2.4 using Datastax driver 
2.1.9.

> Close Java driver Client object in Hadoop and Pig classes
> -
>
> Key: CASSANDRA-10058
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10058
> Project: Cassandra
>  Issue Type: Bug
>Reporter: Alex Liu
>Assignee: Alex Liu
> Fix For: 2.2.4, 3.0.1, 3.1
>
> Attachments: CASSANDRA-10058-2.2.txt
>
>
> I found that some Hadoop and Pig code in Cassandra doesn't close the Client 
> object, that's the cause for the following errors in java driver 2.2.0-rc1.
> {code}
> ERROR 11:37:45 LEAK: You are creating too many HashedWheelTimer instances.  
> HashedWheelTimer is a shared resource that must be reused across the JVM,so 
> that only a few instances are created.
> {code}
> We should close the Client objects.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

2016-01-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101696#comment-15101696
 ] 

James Howe edited comment on CASSANDRA-9328 at 1/15/16 12:46 PM:
-

Am I understanding this correctly? If a SERIAL write throws a 
WriteTimeoutException, I must then perform a SERIAL read to find out whether it 
actually succeeded or not? Or is not that even guaranteed to work?


was (Author: jameshowe):
Am I understanding this correctly? If a SERIAL write throws a 
WriteTimeoutException, I must then perform a SERIAL read to find out whether it 
actually succeeded or not?

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aaron Whiteside
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (CASSANDRA-9328) WriteTimeoutException thrown when LWT concurrency > 1, despite the query duration taking MUCH less than cas_contention_timeout_in_ms

2016-01-15 Thread James Howe (JIRA) 

[ 
https://issues.apache.org/jira/browse/CASSANDRA-9328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15101696#comment-15101696
 ] 

James Howe commented on CASSANDRA-9328:
---

Am I understanding this correctly? If a SERIAL write throws a 
WriteTimeoutException, I must then perform a SERIAL read to find out whether it 
actually succeeded or not?

> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms
> 
>
> Key: CASSANDRA-9328
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9328
> Project: Cassandra
>  Issue Type: Bug
>  Components: Coordination
>Reporter: Aaron Whiteside
> Fix For: 2.1.x
>
> Attachments: CassandraLWTTest.java, CassandraLWTTest2.java
>
>
> WriteTimeoutException thrown when LWT concurrency > 1, despite the query 
> duration taking MUCH less than cas_contention_timeout_in_ms.
> Unit test attached, run against a 3 node cluster running 2.1.5.
> If you reduce the threadCount to 1, you never see a WriteTimeoutException. If 
> the WTE is due to not being able to communicate with other nodes, why does 
> the concurrency >1 cause inter-node communication to fail?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)