[jira] [Commented] (CASSANDRA-2849) InvalidRequestException when validating column data includes entire column value
[ https://issues.apache.org/jira/browse/CASSANDRA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13083169#comment-13083169 ] David Allsopp commented on CASSANDRA-2849: -- Yes, that looks good to me, thanks. InvalidRequestException when validating column data includes entire column value Key: CASSANDRA-2849 URL: https://issues.apache.org/jira/browse/CASSANDRA-2849 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.5 Attachments: 2849-v2.txt, cassandra-2849.diff If the column value fails to validate, then ThriftValidation.validateColumnData() calls bytesToHex() on the entire column value and puts this string in the Exception. Since the value may be up to 2GB, this is potentially a lot of extra memory. The value is likely to be logged (and presumably returned to the thrift client over the network?). This could cause a lot of slowdown or an unnecessary OOM crash, and is unlikely to be useful (the client has access to the full value anyway if required for debugging). Also, the reason for the exception (extracted from the MarshalException) is printed _after_ the data, so if there's any truncation in the logging system at any point, the reason will be lost. The reason should be displayed before the column value, and the column value should be truncated in the Exception message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2335) Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073384#comment-13073384
]
David Allsopp commented on CASSANDRA-2335:
--
Um, not sure, as I'm having a lot of trouble getting Cassandra to build on
Windows reliably (or at all), which is why I've been rather slow on some other
tickets. Eclipse gives a StackOverflowError when it gets to the Target
maven-ant-tasks-retrieve-build (have applied
https://issues.apache.org/jira/browse/CASSANDRA-2687 but doesn't seem to help
here). My Eclipse also crashes intermittently, just to keep life interesting ;-)
I eventually gave up and did a fresh install of Ant and Maven (1.8.2, 3.0.3) so
I could build from the command line. For Cassandra 0.7 I am getting the problem
described at
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Problem-compiling-td6438062.html
- I get
{noformat}
Cassandra-0.7\build.xml:287: artifact:pom doesn't support the groupId
attribute
{noformat}
The change _looks_ good to me, but I can't test at present.
Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
--
Key: CASSANDRA-2335
URL: https://issues.apache.org/jira/browse/CASSANDRA-2335
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0
Environment: Windows
Reporter: Benjamin Coverston
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.9
Attachments: 2335.txt
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2335) Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073384#comment-13073384
]
David Allsopp edited comment on CASSANDRA-2335 at 7/31/11 8:58 PM:
---
Um, not sure, as I'm having a lot of trouble getting Cassandra to build on
Windows reliably (or at all), which is why I've been rather slow on some other
tickets. Eclipse gives a StackOverflowError when it gets to the Target
maven-ant-tasks-retrieve-build (have applied
https://issues.apache.org/jira/browse/CASSANDRA-2687 but doesn't seem to help
here). My Eclipse also crashes intermittently, just to keep life interesting ;-)
[Update - I just found https://issues.apache.org/jira/browse/CASSANDRA-2640
which probably explains the Eclipse problem as my Eclipse's Ant is out of date.]
I eventually gave up and did a fresh install of Ant and Maven (1.8.2, 3.0.3) so
I could build from the command line. For Cassandra 0.7 I am getting the problem
described at
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Problem-compiling-td6438062.html
- I get
{noformat}
Cassandra-0.7\build.xml:287: artifact:pom doesn't support the groupId
attribute
{noformat}
The change _looks_ good to me, but I can't test at present.
was (Author: dallsopp):
Um, not sure, as I'm having a lot of trouble getting Cassandra to build on
Windows reliably (or at all), which is why I've been rather slow on some other
tickets. Eclipse gives a StackOverflowError when it gets to the Target
maven-ant-tasks-retrieve-build (have applied
https://issues.apache.org/jira/browse/CASSANDRA-2687 but doesn't seem to help
here). My Eclipse also crashes intermittently, just to keep life interesting ;-)
I eventually gave up and did a fresh install of Ant and Maven (1.8.2, 3.0.3) so
I could build from the command line. For Cassandra 0.7 I am getting the problem
described at
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Problem-compiling-td6438062.html
- I get
{noformat}
Cassandra-0.7\build.xml:287: artifact:pom doesn't support the groupId
attribute
{noformat}
The change _looks_ good to me, but I can't test at present.
Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
--
Key: CASSANDRA-2335
URL: https://issues.apache.org/jira/browse/CASSANDRA-2335
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0
Environment: Windows
Reporter: Benjamin Coverston
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.9
Attachments: 2335.txt
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2335) Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073384#comment-13073384
]
David Allsopp edited comment on CASSANDRA-2335 at 7/31/11 8:59 PM:
---
Um, not sure, as I'm having a lot of trouble getting Cassandra to build on
Windows reliably (or at all), which is why I've been rather slow on some other
tickets. Eclipse gives a StackOverflowError when it gets to the Target
maven-ant-tasks-retrieve-build (have applied
https://issues.apache.org/jira/browse/CASSANDRA-2687 but doesn't seem to help
here). My Eclipse also crashes intermittently, just to keep life interesting ;-)
Update - I just found https://issues.apache.org/jira/browse/CASSANDRA-2640
which probably explains the Eclipse problem as my Eclipse's Ant is out of date.
I eventually gave up and did a fresh install of Ant and Maven (1.8.2, 3.0.3) so
I could build from the command line. For Cassandra 0.7 I am getting the problem
described at
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Problem-compiling-td6438062.html
- I get
{noformat}
Cassandra-0.7\build.xml:287: artifact:pom doesn't support the groupId
attribute
{noformat}
The change _looks_ good to me, but I can't test at present.
was (Author: dallsopp):
Um, not sure, as I'm having a lot of trouble getting Cassandra to build on
Windows reliably (or at all), which is why I've been rather slow on some other
tickets. Eclipse gives a StackOverflowError when it gets to the Target
maven-ant-tasks-retrieve-build (have applied
https://issues.apache.org/jira/browse/CASSANDRA-2687 but doesn't seem to help
here). My Eclipse also crashes intermittently, just to keep life interesting ;-)
[Update - I just found https://issues.apache.org/jira/browse/CASSANDRA-2640
which probably explains the Eclipse problem as my Eclipse's Ant is out of date.]
I eventually gave up and did a fresh install of Ant and Maven (1.8.2, 3.0.3) so
I could build from the command line. For Cassandra 0.7 I am getting the problem
described at
http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/Problem-compiling-td6438062.html
- I get
{noformat}
Cassandra-0.7\build.xml:287: artifact:pom doesn't support the groupId
attribute
{noformat}
The change _looks_ good to me, but I can't test at present.
Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
--
Key: CASSANDRA-2335
URL: https://issues.apache.org/jira/browse/CASSANDRA-2335
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0
Environment: Windows
Reporter: Benjamin Coverston
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7.9
Attachments: 2335.txt
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2966) AssertionError - No data found for SliceQueryFilter, in ColumnFamilyStore.scan()
AssertionError - No data found for SliceQueryFilter, in ColumnFamilyStore.scan() Key: CASSANDRA-2966 URL: https://issues.apache.org/jira/browse/CASSANDRA-2966 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.7.6 Environment: CentOS under VMWare, Pycassa 1.0.8, Cassandra 0.7.6, 4GB heap Reporter: David Allsopp Fix For: 0.7.9 The following exception appears repeatedly in the system log. There is a single client which is doing get_indexed_slices() at CL.ONE with a buffer size of 4096, iterating through all the matching rows, then starting over with a new get_indexed_slices call. INFO [FlushWriter:353] 2011-06-20 11:29:29,693 Memtable.java (line 172) Completed flushing /var/lib/cassandra/data/Test/Urls.737461747573-f-268-Data.db (123 bytes) INFO [FlushWriter:353] 2011-06-20 11:29:29,693 Memtable.java (line 157) Writing Memtable-Urls@1102022892(44 bytes, 2 operations) INFO [FlushWriter:353] 2011-06-20 11:29:29,700 Memtable.java (line 172) Completed flushing /var/lib/cassandra/data/Test/Urls-f-266-Data.db (186 bytes) INFO [COMMIT-LOG-WRITER] 2011-06-20 11:29:29,701 CommitLog.java (line 442) Discarding obsolete commit log:CommitLogSegment(/var/lib/cassandra/commitlog/CommitLog-1308563547 721.log) ERROR [ReadStage:1065] 2011-06-20 11:29:30,097 AbstractCassandraDaemon.java (line 114) Fatal exception in thread Thread[ReadStage:1065,5,main] java.lang.AssertionError: No data found for SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30], finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], rever sed=false, count=100] in DecoratedKey(46771446669481051451740435757015366511, 687474703a2f2f6f74686572646f6d61696e2f6f6e65):QueryPath(columnFamilyName='Urls', superColumnNam e='null', columnName='null') (original filter SliceQueryFilter(start=java.nio.HeapByteBuffer[pos=10 lim=10 cap=30], finish=java.nio.HeapByteBuffer[pos=17 lim=17 cap=30], rev ersed=false, count=100]) from expression 'Urls.737461747573 EQ 30' at org.apache.cassandra.db.ColumnFamilyStore.scan(ColumnFamilyStore.java:1603) at org.apache.cassandra.service.IndexScanVerbHandler.doVerb(IndexScanVerbHandler.java:42) at org.apache.cassandra.net.MessageDeliveryTask.run(MessageDeliveryTask.java:72) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
[ https://issues.apache.org/jira/browse/CASSANDRA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070578#comment-13070578 ] David Allsopp commented on CASSANDRA-2854: -- Patricio - I think that's a separate problem, but thanks for the tip, as I was getting that problem as well! I couldn't figure out why Eclipse acted as if that src was on the build path, but showed only src/java in the settings! Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target Key: CASSANDRA-2854 URL: https://issues.apache.org/jira/browse/CASSANDRA-2854 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.1 Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse Reporter: David Allsopp Priority: Minor Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C (semicolon, letter C) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067556#comment-13067556 ] David Allsopp edited comment on CASSANDRA-2850 at 7/23/11 10:15 PM: Something funny going on with the versions? - the revision numbers in your patch seem way higher than the ones I can see in SVN for trunk or 0.8 or 0.8.1 branches. I don't see the unit test failures here. -However, I _think_ one bug may be using bytes.get(i) rather than bytes.get(i) 0xff as in the older code, to treat values as unsigned. Will take another look tonight.- was (Author: dallsopp): Something funny going on with the versions? - the revision numbers in your patch seem way higher than the ones I can see in SVN for trunk or 0.8 or 0.8.1 branches. I don't see the unit test failures here. However, I _think_ one bug may be using bytes.get(i) rather than bytes.get(i) 0xff as in the older code, to treat values as unsigned. Will take another look tonight. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.3 Attachments: 2850-rebased.txt, 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070069#comment-13070069 ] David Allsopp commented on CASSANDRA-2850: -- OK - found bug, which only manifests when the ByteBuffer is at a non-zero position - the unit tests that directly test ByteBufferUtil don't test this circumstance, so will add something there, and recheck performance with a fixed version... Oddly, testCleanupWithIndexes (and others) pass fine if I run them from Eclipse individually, but they fail if run via the Ant test task. An aside - I initially couldn't get your patch to apply either - perhaps a newline character issue since I've been doing this work on Windows (never again!) - but, I did discover that it applied fine using the patch function in Eclipse, by setting the 'fuzz factor' to 2. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.3 Attachments: 2850-rebased.txt, 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070069#comment-13070069 ] David Allsopp edited comment on CASSANDRA-2850 at 7/23/11 10:32 PM: OK - found bug, which only manifests when the ByteBuffer is at a non-zero position - the unit tests that directly test ByteBufferUtil don't test this circumstance, so will add something there, and recheck performance with a fixed version... Oddly, testCleanupWithIndexes (and others) pass fine if I run them from Eclipse individually, but they fail if run via the Ant test task. An aside - I initially couldn't get your patch to apply either - perhaps a newline character issue since I've been doing this work on Windows (never again!) - but, I did discover that it applied fine by setting the patch 'fuzz factor' to 2. was (Author: dallsopp): OK - found bug, which only manifests when the ByteBuffer is at a non-zero position - the unit tests that directly test ByteBufferUtil don't test this circumstance, so will add something there, and recheck performance with a fixed version... Oddly, testCleanupWithIndexes (and others) pass fine if I run them from Eclipse individually, but they fail if run via the Ant test task. An aside - I initially couldn't get your patch to apply either - perhaps a newline character issue since I've been doing this work on Windows (never again!) - but, I did discover that it applied fine using the patch function in Eclipse, by setting the 'fuzz factor' to 2. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.3 Attachments: 2850-rebased.txt, 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13070071#comment-13070071 ] David Allsopp commented on CASSANDRA-2850: -- I think the different test behaviour in different contexts is because the tests use Java assert as well as JUnit assertEquals() etc, so are presumably expected to be run with assertions enabled (with -ea). Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.3 Attachments: 2850-rebased.txt, 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2126) RMI call times out on large repair jobs
[
https://issues.apache.org/jira/browse/CASSANDRA-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069514#comment-13069514
]
David Allsopp commented on CASSANDRA-2126:
--
I've just had exactly the same exception for a nodetool loadbalance operation
(on v0.7.6)
RMI call times out on large repair jobs
---
Key: CASSANDRA-2126
URL: https://issues.apache.org/jira/browse/CASSANDRA-2126
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Matthew F. Dennis
Priority: Minor
It looks like when a repair is started via nodetool and the repair takes a
long time the blocking RMI call can timeout before the repair finishes. The
repair will continue to run and correctly complete, but the caller receives a
stack trace similar to:
{noformat}
Exception in thread main java.rmi.UnmarshalException: Error unmarshaling
return header; nested exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:209)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:993)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
at $Proxy0.forceTableRepair(Unknown Source)
at
org.apache.cassandra.tools.NodeProbe.forceTableRepair(NodeProbe.java:155)
at
org.apache.cassandra.tools.NodeCmd.optionalKSandCFs(NodeCmd.java:635)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:546)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:250)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:195)
... 9 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2126) RMI call times out on large repair jobs
[
https://issues.apache.org/jira/browse/CASSANDRA-2126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13069514#comment-13069514
]
David Allsopp edited comment on CASSANDRA-2126 at 7/22/11 11:50 AM:
I've just had almost the same exception for a nodetool loadbalance operation
(on v0.7.6):
{noformat}
$ nodetool -h dev2 -p8080 loadbalance
Exception in thread main java.rmi.UnmarshalException: Error unmarshaling
return header; nested exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:227)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:160)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:1001)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:305)
at $Proxy0.loadBalance(Unknown Source)
at org.apache.cassandra.tools.NodeProbe.loadBalance(NodeProbe.java:352)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:541)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:267)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:213)
... 8 more
{noformat}
was (Author: dallsopp):
I've just had exactly the same exception for a nodetool loadbalance
operation (on v0.7.6)
RMI call times out on large repair jobs
---
Key: CASSANDRA-2126
URL: https://issues.apache.org/jira/browse/CASSANDRA-2126
Project: Cassandra
Issue Type: Bug
Components: Tools
Reporter: Matthew F. Dennis
Priority: Minor
It looks like when a repair is started via nodetool and the repair takes a
long time the blocking RMI call can timeout before the repair finishes. The
repair will continue to run and correctly complete, but the caller receives a
stack trace similar to:
{noformat}
Exception in thread main java.rmi.UnmarshalException: Error unmarshaling
return header; nested exception is:
java.io.EOFException
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:209)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:142)
at com.sun.jmx.remote.internal.PRef.invoke(Unknown Source)
at javax.management.remote.rmi.RMIConnectionImpl_Stub.invoke(Unknown
Source)
at
javax.management.remote.rmi.RMIConnector$RemoteMBeanServerConnection.invoke(RMIConnector.java:993)
at
javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:288)
at $Proxy0.forceTableRepair(Unknown Source)
at
org.apache.cassandra.tools.NodeProbe.forceTableRepair(NodeProbe.java:155)
at
org.apache.cassandra.tools.NodeCmd.optionalKSandCFs(NodeCmd.java:635)
at org.apache.cassandra.tools.NodeCmd.main(NodeCmd.java:546)
Caused by: java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:250)
at
sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:195)
... 9 more
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2931) Nodetool ring prints the same token regardless of node queried
Nodetool ring prints the same token regardless of node queried
--
Key: CASSANDRA-2931
URL: https://issues.apache.org/jira/browse/CASSANDRA-2931
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.6
Reporter: David Allsopp
Priority: Trivial
I have a 3-node test cluster. Using {{nodetool ring}} for any of the nodes
returns the _same_ token at the top of the list
(113427455640312821154458202477256070484) - but presumably this should reflect
the token _of the node I am querying_ (as specified using -h) ? Or if not, what
does it mean?
{noformat}
[dna@dev6 ~]$ nodetool -h dev6 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
[dna@dev6 ~]$ nodetool -h dev8 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
[dna@dev6 ~]$ nodetool -h dev9 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2931) Nodetool ring prints the same token regardless of node queried
[
https://issues.apache.org/jira/browse/CASSANDRA-2931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13068980#comment-13068980
]
David Allsopp commented on CASSANDRA-2931:
--
Thanks - I have edited http://wiki.apache.org/cassandra/NodeTool to spell this
out, as most of the documentation I've seen uses the older format (with the
ASCII ring arrows on the right).
Nodetool ring prints the same token regardless of node queried
--
Key: CASSANDRA-2931
URL: https://issues.apache.org/jira/browse/CASSANDRA-2931
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.6
Reporter: David Allsopp
Priority: Trivial
I have a 3-node test cluster. Using {{nodetool ring}} for any of the nodes
returns the _same_ token at the top of the list
(113427455640312821154458202477256070484) - but presumably this should
reflect the token _of the node I am querying_ (as specified using -h) ? Or if
not, what does it mean?
{noformat}
[dna@dev6 ~]$ nodetool -h dev6 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
[dna@dev6 ~]$ nodetool -h dev8 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
[dna@dev6 ~]$ nodetool -h dev9 -p 8082 ring
Address Status State LoadOwnsToken
113427455640312821154458202477256070484
10.0.11.8 Up Normal 2.41 GB 33.33% 0
10.0.11.6 Up Normal 3.13 GB 33.33%
56713727820156410577229101238628035242
10.0.11.9 Up Normal 1.65 GB 33.33%
113427455640312821154458202477256070484
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13067556#comment-13067556 ] David Allsopp commented on CASSANDRA-2850: -- Something funny going on with the versions? - the revision numbers in your patch seem way higher than the ones I can see in SVN for trunk or 0.8 or 0.8.1 branches. I don't see the unit test failures here. However, I _think_ one bug may be using bytes.get(i) rather than bytes.get(i) 0xff as in the older code, to treat values as unsigned. Will take another look tonight. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-rebased.txt, 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: 2850-v4a.patch 2850-v4a.patch is now against trunk rather than 0.8.1 - is that right? Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, 2850-v4.patch, 2850-v4a.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: 2850-v4.patch OK - the attached patch v4 includes both sets of improvements. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, 2850-v4.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp reassigned CASSANDRA-2850: Assignee: David Allsopp Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Assignee: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, 2850-v4.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[
https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059526#comment-13059526
]
David Allsopp commented on CASSANDRA-2851:
--
The origin of the current behaviour is CASSANDRA-1411
https://issues.apache.org/jira/browse/CASSANDRA-1411 if that helps...
hex-to-bytes conversion accepts invalid inputs silently
---
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.1
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
Attachments: cassandra-2851.diff
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with
an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'?
Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059589#comment-13059589 ] David Allsopp commented on CASSANDRA-2850: -- I think you mean (bytes.remaining() * 2) not (bytes.remaining() / 2) - we need twice as many chars as bytes. Also, shouldn't byteToChar[] have length 16, not 256. Not sure what string creation you are referring to? I attach 2 further versions of bytesToHex (as another benchmark class 3). Results are below (I've had to increasse the number of repeats so the stats are significant!). v3 uses 'normal' code and is another 20% faster for large values, and _another_ factor of 2 faster than v2, i.e. 7-10 time sfatser than the original. v4 uses nasty reflection to avoid doing an arraycopy on the byte array - this avoids a large chunk of memory (all the previous solutions end up doing an arraycopy somewhere). This is now 11-13 times fatser than the original. 20M old: 1482 20M new: 360 20M v2: 249 20M v3: 203 20M v4: 125 old: 2137 new: 859 v2: 718 v3: 203 v4: 156 old: 2138 new: 843 v2: 733 v3: 188 v4: 156 Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark3.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: (was: BytesToHexBenchmark3.java) Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark3.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059589#comment-13059589 ] David Allsopp edited comment on CASSANDRA-2850 at 7/4/11 7:46 PM: -- I think you mean (bytes.remaining() * 2) not (bytes.remaining() / 2) - we need twice as many chars as bytes. Also, shouldn't byteToChar[] have length 16, not 256? Not sure what string creation you are referring to? I attach 2 further versions of bytesToHex (as another benchmark class 3). Results are below (I've had to increase the number of repeats so the stats are significant!). v3 uses 'normal' code and is another 20% faster for large values, and _another_ factor of 2 faster than v2, i.e. 7-10 times faster than the original. v4 uses nasty reflection to avoid doing an arraycopy on the byte array - this avoids a large chunk of memory (all the previous solutions end up doing an arraycopy somewhere). This is now 11-13 times faster than the original. 20M old: 1482 20M new: 360 20M v2: 249 20M v3: 203 20M v4: 125 old: 2137 new: 859 v2: 718 v3: 203 v4: 156 old: 2138 new: 843 v2: 733 v3: 188 v4: 156 was (Author: dallsopp): I think you mean (bytes.remaining() * 2) not (bytes.remaining() / 2) - we need twice as many chars as bytes. Also, shouldn't byteToChar[] have length 16, not 256. Not sure what string creation you are referring to? I attach 2 further versions of bytesToHex (as another benchmark class 3). Results are below (I've had to increasse the number of repeats so the stats are significant!). v3 uses 'normal' code and is another 20% faster for large values, and _another_ factor of 2 faster than v2, i.e. 7-10 time sfatser than the original. v4 uses nasty reflection to avoid doing an arraycopy on the byte array - this avoids a large chunk of memory (all the previous solutions end up doing an arraycopy somewhere). This is now 11-13 times fatser than the original. 20M old: 1482 20M new: 360 20M v2: 249 20M v3: 203 20M v4: 125 old: 2137 new: 859 v2: 718 v3: 203 v4: 156 old: 2138 new: 843 v2: 733 v3: 188 v4: 156 Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059595#comment-13059595 ] David Allsopp commented on CASSANDRA-2850: -- An issue with using hex at all is that we can't represent the maximum 2GB column value. If we have Integer.MAX_VALUE bytes, then we need twice as many chars - and arrays in Java are limited to Integer.MAX_VALUE. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059607#comment-13059607 ] David Allsopp commented on CASSANDRA-2850: -- I can't improve any further on Sylvain's hexToByte - nice work! Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark3.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: (was: BytesToHexBenchmark3.java) Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059622#comment-13059622 ] David Allsopp commented on CASSANDRA-2850: -- Update - the benchmark version 3 was running v3 twice, not v3 then v4. Have re-attached. New results are: 20M old: 1435 20M new: 376 20M v2: 405 20M v3: 141 20M v4: 93 20M old: 1265 20M new: 360 20M v2: 234 20M v3: 187 20M v4: 78 20M old: 1233 20M new: 376 20M v2: 452 20M v3: 125 20M v4: 63 old: 2184 new: 906 v2: 577 v3: 188 v4: 172 old: 2215 new: 937 v2: 593 v3: 188 v4: 156 Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: (was: BytesToHexBenchmark3.java) Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark3.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059622#comment-13059622 ] David Allsopp edited comment on CASSANDRA-2850 at 7/4/11 9:48 PM: -- Update - the benchmark version 3 was running v3 twice, not v3 then v4. Have re-attached. New results are 15-19x faster for 20MB values, 13-14x faster for 1KB values. 20M old: 1435 20M new: 376 20M v2: 405 20M v3: 141 20M v4: 93 20M old: 1265 20M new: 360 20M v2: 234 20M v3: 187 20M v4: 78 20M old: 1233 20M new: 376 20M v2: 452 20M v3: 125 20M v4: 63 old: 2184 new: 906 v2: 577 v3: 188 v4: 172 old: 2215 new: 937 v2: 593 v3: 188 v4: 156 was (Author: dallsopp): Update - the benchmark version 3 was running v3 twice, not v3 then v4. Have re-attached. New results are: 20M old: 1435 20M new: 376 20M v2: 405 20M v3: 141 20M v4: 93 20M old: 1265 20M new: 360 20M v2: 234 20M v3: 187 20M v4: 78 20M old: 1233 20M new: 376 20M v2: 452 20M v3: 125 20M v4: 63 old: 2184 new: 906 v2: 577 v3: 188 v4: 172 old: 2215 new: 937 v2: 593 v3: 188 v4: 156 Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059633#comment-13059633 ] David Allsopp commented on CASSANDRA-2850: -- Although the bytesToHex reflection hack is a bit horrible, it makes a huge difference with really big values - I've just been trying different input sizes (with -Xmx4g -Xms4g on a 6GB machine) and the JVM falls over with OOM at about 300MB for all the other versions, but copes with 675MB for v4. With the other versions, for byte array size N, we also need at least 2N for the StringBuilder or char[], then another 2N for the String (because the normal String constructors and methods always do an arraycopy of the input byte[] - 5N. I wonder where else in the code this sort of thing occurs...? Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: 2850-v2.patch, BytesToHexBenchmark.java, BytesToHexBenchmark2.java, BytesToHexBenchmark3.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2849) InvalidRequestException when validating column data includes entire column value
InvalidRequestException when validating column data includes entire column value Key: CASSANDRA-2849 URL: https://issues.apache.org/jira/browse/CASSANDRA-2849 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 If the column value fails to validate, then ThriftValidation.validateColumnData() calls bytesToHex() on the entire column value and puts this string in the Exception. Since the value may be up to 2GB, this is potentially a lot of extra memory. The value is likely to be logged (and presumably returned to the thrift client over the network?). This could cause a lot of slowdown or an unnecessary OOM crash, and is unlikely to be useful (the client has access to the full value anyway if required for debugging). Also, the reason for the exception (extracted from the MarshalException) is printed _after_ the data, so if there's any truncation in the logging system at any point, the reason will be lost. The reason should be displayed before the column value, and the column value should be truncated in the Exception message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2849) InvalidRequestException when validating column data includes entire column value
[ https://issues.apache.org/jira/browse/CASSANDRA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2849: - Attachment: cassandra-2849.diff Attached diff moves the reason for the exception before the data, and truncates the column value data in the exception to 64K. Unable to test this properly today since working on a fresh Windows box over the weekend and unable to get build working in Eclipse 8-( InvalidRequestException when validating column data includes entire column value Key: CASSANDRA-2849 URL: https://issues.apache.org/jira/browse/CASSANDRA-2849 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: cassandra-2849.diff If the column value fails to validate, then ThriftValidation.validateColumnData() calls bytesToHex() on the entire column value and puts this string in the Exception. Since the value may be up to 2GB, this is potentially a lot of extra memory. The value is likely to be logged (and presumably returned to the thrift client over the network?). This could cause a lot of slowdown or an unnecessary OOM crash, and is unlikely to be useful (the client has access to the full value anyway if required for debugging). Also, the reason for the exception (extracted from the MarshalException) is printed _after_ the data, so if there's any truncation in the logging system at any point, the reason will be lost. The reason should be displayed before the column value, and the column value should be truncated in the Exception message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2849) InvalidRequestException when validating column data includes entire column value
[ https://issues.apache.org/jira/browse/CASSANDRA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059215#comment-13059215 ] David Allsopp commented on CASSANDRA-2849: -- A lot of classes use ByteBufferUtil.bytesToHex(), often for logging and exceptions, so may make more sense to add a method there for getting a truncated hex string. InvalidRequestException when validating column data includes entire column value Key: CASSANDRA-2849 URL: https://issues.apache.org/jira/browse/CASSANDRA-2849 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: cassandra-2849.diff If the column value fails to validate, then ThriftValidation.validateColumnData() calls bytesToHex() on the entire column value and puts this string in the Exception. Since the value may be up to 2GB, this is potentially a lot of extra memory. The value is likely to be logged (and presumably returned to the thrift client over the network?). This could cause a lot of slowdown or an unnecessary OOM crash, and is unlikely to be useful (the client has access to the full value anyway if required for debugging). Also, the reason for the exception (extracted from the MarshalException) is printed _after_ the data, so if there's any truncation in the logging system at any point, the reason will be lost. The reason should be displayed before the column value, and the column value should be truncated in the Exception message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2849) InvalidRequestException when validating column data includes entire column value
[ https://issues.apache.org/jira/browse/CASSANDRA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059221#comment-13059221 ] David Allsopp commented on CASSANDRA-2849: -- On a related note, I just noticed that ByteBufferUtil.bytesToHex() is unnecessarily slow - will raise a new issue for this. InvalidRequestException when validating column data includes entire column value Key: CASSANDRA-2849 URL: https://issues.apache.org/jira/browse/CASSANDRA-2849 Project: Cassandra Issue Type: Bug Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: cassandra-2849.diff If the column value fails to validate, then ThriftValidation.validateColumnData() calls bytesToHex() on the entire column value and puts this string in the Exception. Since the value may be up to 2GB, this is potentially a lot of extra memory. The value is likely to be logged (and presumably returned to the thrift client over the network?). This could cause a lot of slowdown or an unnecessary OOM crash, and is unlikely to be useful (the client has access to the full value anyway if required for debugging). Also, the reason for the exception (extracted from the MarshalException) is printed _after_ the data, so if there's any truncation in the logging system at any point, the reason will be lost. The reason should be displayed before the column value, and the column value should be truncated in the Exception message. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, cassandra-2850.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: cassandra-2850.diff Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, cassandra-2850.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Affects Version/s: 0.7.6 Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, cassandra-2850.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059239#comment-13059239 ] David Allsopp commented on CASSANDRA-2850: -- Just a note as to why might matter (in the absence of hard profiling data) - hexToBytes() is called in a lot of places in the code, and is sometimes called on the entire column value. A column value of 10MB takes over 750ms to convert on my machine (180ms with the patch), so it's significant load - and column values go up to 2GB (extrapolating linearly, 2GB could take over 2 minutes to convert, assuming you've got the spare RAM!). Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, cassandra-2850.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059241#comment-13059241 ] David Allsopp commented on CASSANDRA-2850: -- Just noticed that there's a bytesToHex(byte... bytes) method in FBUtilities - whatever implementation is chosen, these methods probably ought to be together? Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, cassandra-2850.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
hex-to-bytes conversion accepts invalid inputs silently
---
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.8.1, 0.7.6
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with an
odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't
this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{, 000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[
https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059246#comment-13059246
]
David Allsopp commented on CASSANDRA-2851:
--
In addition to the invalid values, should probably also add a check in
FBUtilitiesTest.testHexToBytesStringConversion() that is converted to
byte[0], and that a null input is handled appropriately.
hex-to-bytes conversion accepts invalid inputs silently
---
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.1
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with
an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'?
Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{, 000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[
https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Allsopp updated CASSANDRA-2851:
-
Description:
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with an
odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't
this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
was:
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with an
odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'? Isn't
this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{, 000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
hex-to-bytes conversion accepts invalid inputs silently
---
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.1
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with
an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'?
Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2851) hex-to-bytes conversion accepts invalid inputs silently
[
https://issues.apache.org/jira/browse/CASSANDRA-2851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Allsopp updated CASSANDRA-2851:
-
Attachment: cassandra-2851.diff
If there's agreement that odd-sized inputs should throw an exception, the
attached patch does this and updates the unit test.
hex-to-bytes conversion accepts invalid inputs silently
---
Key: CASSANDRA-2851
URL: https://issues.apache.org/jira/browse/CASSANDRA-2851
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.7.6, 0.8.1
Reporter: David Allsopp
Priority: Minor
Fix For: 0.8.2
Attachments: cassandra-2851.diff
FBUtilities.hexToBytes() has a minor bug - it copes with single-character
inputs by prepending 0, which is OK - but it does this for any input with
an odd number of characters, which is probably incorrect.
{noformat}
if (str.length() % 2 == 1)
str = 0 + str;
{noformat}
Given 'fff' as an input, can we really assume that this should be '0fff'?
Isn't this just an error?
Add the following to FBUtilitiesTest to demonstrate:
{noformat}
String[] badvalues = new String[]{000, fff};
for (int i = 0; i badvalues.length; i++)
try
{
FBUtilities.hexToBytes(badvalues[i]);
fail(Invalid hex value accepted+badvalues[i]);
} catch (Exception e){}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: (was: BytesToHexBenchmark.java) Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: cassandra-2850a.diff Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: (was: cassandra-2850.diff) Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2850: - Attachment: BytesToHexBenchmark2.java BytesToHexBenchmark.java Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2850) Converting bytes to hex string is unnecessarily slow
[ https://issues.apache.org/jira/browse/CASSANDRA-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059268#comment-13059268 ] David Allsopp commented on CASSANDRA-2850: -- Updated diff (2850a) includes the same optimisation in both the FBUtilities version and the ByteBufferUtils version, with similar x3 speedup in each case. Now uses a literal lookup table rather than generating it in static block. Converting bytes to hex string is unnecessarily slow Key: CASSANDRA-2850 URL: https://issues.apache.org/jira/browse/CASSANDRA-2850 Project: Cassandra Issue Type: Improvement Components: Core Affects Versions: 0.7.6, 0.8.1 Reporter: David Allsopp Priority: Minor Fix For: 0.8.2 Attachments: BytesToHexBenchmark.java, BytesToHexBenchmark2.java, cassandra-2850a.diff ByteBufferUtil.bytesToHex() is unnecessarily slow - it doesn't pre-size the StringBuilder (so several re-sizes will be needed behind the scenes) and it makes quite a few method calls per byte. (OK, this may be a premature optimisation, but I couldn't resist, and it's a small change) Will attach patch shortly that speeds it up by about x3, plus benchmarking test. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target Key: CASSANDRA-2854 URL: https://issues.apache.org/jira/browse/CASSANDRA-2854 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.1 Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse Reporter: David Allsopp Priority: Minor Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C' (semicolon, letter C, single quote) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
[ https://issues.apache.org/jira/browse/CASSANDRA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2854: - Description: Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C (semicolon, letter C) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' was: Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C' (semicolon, letter C, single quote) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target Key: CASSANDRA-2854 URL: https://issues.apache.org/jira/browse/CASSANDRA-2854 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.1 Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse Reporter: David Allsopp Priority: Minor Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C (semicolon, letter C) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
[ https://issues.apache.org/jira/browse/CASSANDRA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059296#comment-13059296 ] David Allsopp commented on CASSANDRA-2854: -- Manually editing all the build path entries (and removing the one called just ';C' ) seems to resolve all the Eclipse project errors. Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target Key: CASSANDRA-2854 URL: https://issues.apache.org/jira/browse/CASSANDRA-2854 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8.1 Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse Reporter: David Allsopp Priority: Minor Following the instructions in http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out v0.8.1: After running the 'generate-eclipse-files' Ant target, the build path is set up to include all the libraries in build/lib/jars, but each library has ;C (semicolon, letter C) appended to it, so Eclipse can't find the libraries - there are about 55 errors like: Project 'cassandra-0.8.1' is missing required library: '\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C' -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2335) Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
[
https://issues.apache.org/jira/browse/CASSANDRA-2335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059302#comment-13059302
]
David Allsopp commented on CASSANDRA-2335:
--
The assertion failure comes from Descriptor.java:
{noformat}
public static Descriptor fromFilename(String filename)
{
int separatorPos = filename.lastIndexOf(File.separatorChar);
assert separatorPos != -1 : Filename must include parent directory.;
...
{noformat}
Windows: Test org.apache.cassandra.streaming.SerializationsTest FAILED
--
Key: CASSANDRA-2335
URL: https://issues.apache.org/jira/browse/CASSANDRA-2335
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.7.0
Environment: Windows
Reporter: Benjamin Coverston
Assignee: Joaquin Casares
Priority: Minor
Fix For: 0.7.7
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2854) Java Build Path is broken in Eclipse after running generate-eclipse-files Ant target
[
https://issues.apache.org/jira/browse/CASSANDRA-2854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059303#comment-13059303
]
David Allsopp commented on CASSANDRA-2854:
--
The Ant target has the following (javascript:
{noformat}
jars = project.getProperty(eclipse-project-libs).split(:);
{noformat}
which is probably picking up on the colon in windows paths such as
{noformat}
C:\Users\Foo\eclipse_workspace\cassandra-0.8.1\build\lib\foo.jar
{noformat}
Java Build Path is broken in Eclipse after running generate-eclipse-files Ant
target
Key: CASSANDRA-2854
URL: https://issues.apache.org/jira/browse/CASSANDRA-2854
Project: Cassandra
Issue Type: Bug
Components: Packaging
Affects Versions: 0.8.1
Environment: Windows 7 64-bit, Eclipse Helios SR1, Subclipse
Reporter: David Allsopp
Priority: Minor
Following the instructions in
http://wiki.apache.org/cassandra/RunningCassandraInEclipse, but checking out
v0.8.1:
After running the 'generate-eclipse-files' Ant target, the build path is set
up to include all the libraries in build/lib/jars, but each library has ;C
(semicolon, letter C) appended to it, so Eclipse can't find the libraries -
there are about 55 errors like:
Project 'cassandra-0.8.1' is missing required library:
'\Users\David\eclipse_workspace\cassandra-0.8.1\build\lib\jars\commons-cli-1.2.jar;C'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056826#comment-13056826
]
David Allsopp edited comment on CASSANDRA-2383 at 7/2/11 9:27 AM:
--
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// load from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
}
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration: +config);
String configFileName = null;
try
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert log4j
configuration location to a valid file., e);
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
was (Author: dallsopp):
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
String configFileName = null;
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// load from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration.);
try
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert
log4j configuration location to a valid file., e);
}
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
log4j unable to load properties file from classpath
---
Key: CASSANDRA-2383
URL: https://issues.apache.org/jira/browse/CASSANDRA-2383
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.4
Environment: OS : windows
java : 1.6.0.23
Reporter: david lee
Assignee: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
when cassandra home folder is placed inside a folder which has space
characters in its name,
log4j settings are not properly loaded and warning messages are shown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059008#comment-13059008 ] David Allsopp commented on CASSANDRA-2383: -- OK, have edited the code snippet above to hopefully fix the obvious broken-ness! Still struggling to get Cassandra building properly on Windows/Eclipse so haven't yet been able to test properly though (need to work through http://wiki.apache.org/cassandra/RunningCassandraInEclipse again from scratch as it didn't seem to work first time round...) log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059011#comment-13059011 ] David Allsopp commented on CASSANDRA-2383: -- The above code seems to work for full hierarchical URIs: -Dlog4j.configuration=file:///C:/conf%20space/log4j-server.properties and for classpath locations: -Dlog4j.configuration=log4j-server.properties (on windows, with a space in the file path) It does not work for opaque URIs such as file:log4j-server.properties because you can't construct a File directly from these (you get java.lang.IllegalArgumentException: URI is not hierarchical) log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056826#comment-13056826
]
David Allsopp edited comment on CASSANDRA-2383 at 7/2/11 10:22 AM:
---
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// then try loading from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
}
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration: +config);
// Now convert URL to a filename
String configFileName = null;
try
{
// first try URL.getFile() which works for opaque URLs
(file:foo) and paths without spaces
configFileName = configLocation.getFile();
File configFile = new File(configFileName);
// then try alternative approach which works for all
hierarchical URLs with or without spaces
if(!configFile.exists())
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert log4j
configuration location to a valid file., e);
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
was (Author: dallsopp):
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// load from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
}
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration: +config);
String configFileName = null;
try
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert log4j
configuration location to a valid file., e);
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
log4j unable to load properties file from classpath
---
Key: CASSANDRA-2383
URL: https://issues.apache.org/jira/browse/CASSANDRA-2383
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.4
Environment: OS : windows
java : 1.6.0.23
Reporter: david lee
Assignee: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
when cassandra home folder is placed inside a folder which has space
characters in its name,
log4j settings are not properly loaded and warning messages are shown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13059014#comment-13059014 ] David Allsopp commented on CASSANDRA-2383: -- OK, third time lucky I hope. The edited version above now tries the original getFile() approach, then falls back on the new File(url.toURI()) approach if the file doesn't exist. This seems to work with classpath names, opaque URIs *and* hierarchical URIs log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2383: - Attachment: cassandra-0.7.6-2-2383.diff log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 Attachments: cassandra-0.7.6-2-2383.diff when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057223#comment-13057223 ] David Allsopp commented on CASSANDRA-2383: -- Yes, that'll teach me to post code late at night :-( log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056794#comment-13056794
]
David Allsopp commented on CASSANDRA-2383:
--
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat}
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat}
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces, and you can verify that the file exists. If
there are spaces, then this conversion produces a filename that includes the
%20 encoding for spaces - this is an incorrect filename.
We need instead to convert using:
{noformat}
new File(configLocation.toURI());
{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
log4j unable to load properties file from classpath
---
Key: CASSANDRA-2383
URL: https://issues.apache.org/jira/browse/CASSANDRA-2383
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.4
Environment: OS : windows
java : 1.6.0.23
Reporter: david lee
Assignee: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
when cassandra home folder is placed inside a folder which has space
characters in its name,
log4j settings are not properly loaded and warning messages are shown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056794#comment-13056794
]
David Allsopp edited comment on CASSANDRA-2383 at 6/28/11 9:24 PM:
---
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat} configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat} log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces; one can verify that the file exists
(File.exists() == true). If there are spaces, then this conversion produces a
filename that includes the %20 encoding for spaces - this is an incorrect
filename.
We need instead to convert using:
{noformat} new File(configLocation.toURI());{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
was (Author: dallsopp):
OK, have gone around in circles a bit on this!
-Dlog4j.defaultInitOverride enables AbstractCassandraDaemon to take charge of
the log4j configuration in order to make it dynamic (you can change the log4j
config file, and it should be updated using the log4j PropertyConfigurator
every 10 seconds).
The default value of log4j.configuration in the code and in the batch file is
log4j-server.properties, which is not a valid URL, so we drop into:
{noformat}
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
{noformat}
as you said before. This *does* detect the correct file from
CASSANDRA_HOME/conf, since log4j logs the *full path* even though we only
supply the filename log4j-server.properties:
{noformat}
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
{noformat}
getResource() returns a URL. Converting this to a file using getFile() works
fine when there are no spaces, and you can verify that the file exists. If
there are spaces, then this conversion produces a filename that includes the
%20 encoding for spaces - this is an incorrect filename.
We need instead to convert using:
{noformat}
new File(configLocation.toURI());
{noformat}
(with appropriate exception handling for URISyntaxException) which produces a
filename with spaces rather than %20.
log4j unable to load properties file from classpath
---
Key: CASSANDRA-2383
URL: https://issues.apache.org/jira/browse/CASSANDRA-2383
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.4
Environment: OS : windows
java : 1.6.0.23
Reporter: david lee
Assignee: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
when cassandra home folder is placed inside a folder which has space
characters in its name,
log4j settings are not properly loaded and warning messages are shown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13056826#comment-13056826
]
David Allsopp commented on CASSANDRA-2383:
--
Suggested fix for AbstractCassandraDaemon static initializer (apologies -
haven't got a suitable version of diff on this windows box yet). Untested on
linux as yet.
{noformat}
//Initialize logging in such a way that it checks for config changes every
10 seconds.
static
{
String config = System.getProperty(log4j.configuration,
log4j-server.properties);
String configFileName = null;
URL configLocation = null;
try
{
// try loading from a physical location first.
configLocation = new URL(config);
}
catch (MalformedURLException ex)
{
// load from the classpath.
configLocation =
AbstractCassandraDaemon.class.getClassLoader().getResource(config);
if (configLocation == null)
throw new RuntimeException(Couldn't figure out log4j
configuration.);
try
{
configFileName = new
File(configLocation.toURI()).getCanonicalPath();
}
catch (Exception e)
{
throw new RuntimeException(Couldn't convert
log4j configuration location to a valid file., e);
}
}
PropertyConfigurator.configureAndWatch(configFileName, 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
{noformat}
log4j unable to load properties file from classpath
---
Key: CASSANDRA-2383
URL: https://issues.apache.org/jira/browse/CASSANDRA-2383
Project: Cassandra
Issue Type: Bug
Components: Tools
Affects Versions: 0.7.4
Environment: OS : windows
java : 1.6.0.23
Reporter: david lee
Assignee: T Jake Luciani
Priority: Minor
Fix For: 0.7.7
when cassandra home folder is placed inside a folder which has space
characters in its name,
log4j settings are not properly loaded and warning messages are shown.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055726#comment-13055726 ] David Allsopp commented on CASSANDRA-2383: -- In cassandra.bat, change: -Dlog4j.configuration=log4j-server.properties^ to: -Dlog4j.configuration=file:///%CASSANDRA_HOME%/conf/log4j-server.properties^ I'm hopeful there's a less ugly way, but this seems to work. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055734#comment-13055734 ] David Allsopp commented on CASSANDRA-2383: -- OK, simpler solution is: -Dlog4j.configuration=file:conf/log4j-server.properties^ cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055734#comment-13055734 ] David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 8:39 PM: --- OK, simpler solution is: -Dlog4j.configuration=file:conf/log4j-server.properties^ But note that this only works if the current directory is CASSANDRA_HOME, so double-clicking on the batch file won't work, whereas the previous solution will work from the 'bin' directory, so double-clicking is OK. was (Author: dallsopp): OK, simpler solution is: -Dlog4j.configuration=file:conf/log4j-server.properties^ cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055782#comment-13055782 ] David Allsopp commented on CASSANDRA-2383: -- Another solution that seems to work regardless of working directory is leave the original log4j.configuration line, but remove the line: -Dlog4j.defaultInitOverride=true^ This gets the classloader to find the config file as a resource, rather than supplying a file reference directly. However, I'm unsure why the defaultInitOverride was there in the first place... cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792 ] David Allsopp commented on CASSANDRA-2383: -- @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792 ] David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 10:00 PM: @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. was (Author: dallsopp): @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For:
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792 ] David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 9:59 PM: --- @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. was (Author: dallsopp): @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does no t exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Documents/Work/Coding/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792 ] David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 10:00 PM: @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. was (Author: dallsopp): @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.prop erties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/co nf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792 ] David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 10:04 PM: @Jonathan - yes, I thought so too, but it doesn't. The default init process for log4j is described at http://logging.apache.org/log4j/1.2/manual.html, but it doesn't really explain what happens if defaultInitOverride is set! With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. was (Author: dallsopp): @Jonathan - yes, I thought so too, but it doesn't. With -Dlog4j.debug=true and the original batch file, i.e. -Dlog4j.configuration=log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I see: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. If I remove the defaultInitOverride, I get: Starting Cassandra Server log4j: [/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] does not exist. log4j: Trying to find [log4j-server.properties] using context classloader sun.misc.Launcher$AppClassLoader@1a45a877. log4j: Using URL [file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties] for automatic log4j configuration. log4j: Reading configuration from URL file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties [etc...] Finally, with: -Dlog4j.configuration=file:conf/log4j-server.properties^ -Dlog4j.defaultInitOverride=true^ I get this, if current directory is CASSANDRA_HOME: Starting Cassandra Server log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. [etc...] But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking the batch file): Starting Cassandra Server log4j: [conf/log4j-server.properties] does not exist. log4j: Default initialization of overridden by log4j.defaultInitOverrideproperty. log4j:WARN No appenders could be found for logger (org.apache.cassandra.service.AbstractCassandraDaemon). log4j:WARN Please initialize the log4j system properly. log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info. cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4
[jira] [Commented] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055800#comment-13055800 ] David Allsopp commented on CASSANDRA-2383: -- http://www.vipan.com/htdocs/log4jhelp.html has the following: log4j.configuration=app_config.properties: First call to Category.getRoot() or Category.getInstance(...) method makes Log4j go through an initialization process. (You can watch that happening by setting log4j.debug=true.) During this process, Log4j looks in the application's classpath for a log4j.properties file *or the properties file you specify* via the this property key. However, you need to set this as a system property, for example by running your program with java -Dlog4j.configuration=app_config.properties This is because, if you set it in the configuration file, it is too late. Log4j would have already started to read the log4j.properties file by default, if available! cassandra.bat does not handle folder names with space characters on windows --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: Benjamin Coverston Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2383) cassandra.bat does not handle folder names with space characters on windows
[
https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055792#comment-13055792
]
David Allsopp edited comment on CASSANDRA-2383 at 6/27/11 10:13 PM:
@Jonathan - yes, I thought so too, but it doesn't. The default init process for
log4j is described at http://logging.apache.org/log4j/1.2/manual.html, but it
doesn't really explain what happens if defaultInitOverride is set!
With -Dlog4j.debug=true and the original batch file, i.e.
{quote}
-Dlog4j.configuration=log4j-server.properties^
-Dlog4j.defaultInitOverride=true^}}
{quote}
I see:
{quote}
Starting Cassandra Server
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.service.AbstractCassandraDaemon).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
{quote}
If I remove the defaultInitOverride, I get:
{quote}
Starting Cassandra Server
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
log4j: Trying to find [log4j-server.properties] using context classloader
sun.misc.Launcher$AppClassLoader@1a45a877.
log4j: Using URL
[file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
for automatic log4j configuration.
log4j: Reading configuration from URL
file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties
[etc...]
{quote}
Finally, with:
{quote}
-Dlog4j.configuration=file:conf/log4j-server.properties^
-Dlog4j.defaultInitOverride=true^
{quote}
I get this, if current directory is CASSANDRA_HOME:
{quote}
Starting Cassandra Server
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
[etc...]
{quote}
But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking
the batch file):
{quote}
Starting Cassandra Server
log4j: [conf/log4j-server.properties] does not exist.
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.service.AbstractCassandraDaemon).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
{quote}
was (Author: dallsopp):
@Jonathan - yes, I thought so too, but it doesn't. The default init process
for log4j is described at http://logging.apache.org/log4j/1.2/manual.html, but
it doesn't really explain what happens if defaultInitOverride is set!
With -Dlog4j.debug=true and the original batch file, i.e.
-Dlog4j.configuration=log4j-server.properties^
-Dlog4j.defaultInitOverride=true^
I see:
Starting Cassandra Server
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.service.AbstractCassandraDaemon).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
If I remove the defaultInitOverride, I get:
Starting Cassandra Server
log4j:
[/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
does not exist.
log4j: Trying to find [log4j-server.properties] using context classloader
sun.misc.Launcher$AppClassLoader@1a45a877.
log4j: Using URL
[file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties]
for automatic log4j configuration.
log4j: Reading configuration from URL
file:/C:/Users/David/Key%20Value/apache-cassandra-0.7.6-2/conf/log4j-server.properties
[etc...]
Finally, with:
-Dlog4j.configuration=file:conf/log4j-server.properties^
-Dlog4j.defaultInitOverride=true^
I get this, if current directory is CASSANDRA_HOME:
Starting Cassandra Server
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
[etc...]
But this, if current directory is CASSANDRA_HOME/bin (e.g. if double-clicking
the batch file):
Starting Cassandra Server
log4j: [conf/log4j-server.properties] does not exist.
log4j: Default initialization of overridden by
log4j.defaultInitOverrideproperty.
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.service.AbstractCassandraDaemon).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
cassandra.bat does not handle folder names with space characters on windows
[jira] [Commented] (CASSANDRA-2383) log4j unable to load properties file from classpath
[ https://issues.apache.org/jira/browse/CASSANDRA-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13055807#comment-13055807 ] David Allsopp commented on CASSANDRA-2383: -- @Jonathan - will try to take a look soon. The getResource() stuff might perhaps be affected by the classes being within a jarfile. log4j unable to load properties file from classpath --- Key: CASSANDRA-2383 URL: https://issues.apache.org/jira/browse/CASSANDRA-2383 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.4 Environment: OS : windows java : 1.6.0.23 Reporter: david lee Assignee: T Jake Luciani Priority: Minor Fix For: 0.7.7 when cassandra home folder is placed inside a folder which has space characters in its name, log4j settings are not properly loaded and warning messages are shown. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2757) Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI
Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI - Key: CASSANDRA-2757 URL: https://issues.apache.org/jira/browse/CASSANDRA-2757 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.6 Environment: Any. Reporter: David Allsopp Priority: Trivial When describing a keyspace, the CLI produces output for each column family, including the 3 memtable thresholds. However, the labels are in the wrong order - the 2nd value is actually the MB, and the 3rd value is actually the minutes: describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/15/1440 (millions of ops/minutes/MB) ... update column family MyTestColFam with memtable_throughput = 128; describe keyspace Test; ... Memtable thresholds: 0.0703125/128/1440 (millions of ops/minutes/MB) ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2757) Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Allsopp updated CASSANDRA-2757: - Description: When describing a keyspace, the CLI produces output for each column family, including the 3 memtable thresholds. However, the labels are in the wrong order - the 2nd value is actually the MB, and the 3rd value is actually the minutes: describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/15/1440 (millions of ops/minutes/MB) ... update column family MyTestColFam with memtable_throughput = 128; describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/128/1440 (millions of ops/minutes/MB) ... was: When describing a keyspace, the CLI produces output for each column family, including the 3 memtable thresholds. However, the labels are in the wrong order - the 2nd value is actually the MB, and the 3rd value is actually the minutes: describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/15/1440 (millions of ops/minutes/MB) ... update column family MyTestColFam with memtable_throughput = 128; describe keyspace Test; ... Memtable thresholds: 0.0703125/128/1440 (millions of ops/minutes/MB) ... Fixed typo in example output Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI - Key: CASSANDRA-2757 URL: https://issues.apache.org/jira/browse/CASSANDRA-2757 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.6 Environment: Any. Reporter: David Allsopp Priority: Trivial Labels: documentation When describing a keyspace, the CLI produces output for each column family, including the 3 memtable thresholds. However, the labels are in the wrong order - the 2nd value is actually the MB, and the 3rd value is actually the minutes: describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/15/1440 (millions of ops/minutes/MB) ... update column family MyTestColFam with memtable_throughput = 128; describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/128/1440 (millions of ops/minutes/MB) ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2757) Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI
[ https://issues.apache.org/jira/browse/CASSANDRA-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13047198#comment-13047198 ] David Allsopp commented on CASSANDRA-2757: -- Agreed; apologies for duplication. Memtable thresholds (millions of ops/minutes/MB) mis-labelled when using describe keyspace in CLI - Key: CASSANDRA-2757 URL: https://issues.apache.org/jira/browse/CASSANDRA-2757 Project: Cassandra Issue Type: Bug Components: Tools Affects Versions: 0.7.6 Environment: Any. Reporter: David Allsopp Priority: Trivial Labels: documentation When describing a keyspace, the CLI produces output for each column family, including the 3 memtable thresholds. However, the labels are in the wrong order - the 2nd value is actually the MB, and the 3rd value is actually the minutes: describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/15/1440 (millions of ops/minutes/MB) ... update column family MyTestColFam with memtable_throughput = 128; describe keyspace MyTestKeyspace; ... Memtable thresholds: 0.0703125/128/1440 (millions of ops/minutes/MB) ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
