[jira] [Commented] (CASSANDRA-803) remove PropertyConfigurator from CassandraDaemon
[
https://issues.apache.org/jira/browse/CASSANDRA-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13023636#comment-13023636
]
Oleg Tsvinev commented on CASSANDRA-803:
I see PropertyConfigurator still there, as of version 0.7.4.
public abstract class AbstractCassandraDaemon implements CassandraDaemon
{
//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.);
}
---PropertyConfigurator.configureAndWatch(configLocation.getFile(), 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
private static Logger logger =
LoggerFactory.getLogger(AbstractCassandraDaemon.class);
remove PropertyConfigurator from CassandraDaemon
Key: CASSANDRA-803
URL: https://issues.apache.org/jira/browse/CASSANDRA-803
Project: Cassandra
Issue Type: Bug
Components: Core
Affects Versions: 0.6
Reporter: Jesse McConnell
In order for users to make use of the EmbeddedCassandraService for unit
testing they need to have a dependency declared on log4j.
It would be nice if we could use the log4j-over-slf4j artifact to bridge this
requirement for those of us using slf4j.
http://www.slf4j.org/legacy.html#log4j-over-slf4j
Currently it errors with the direct usage of the PropertyConfigurator in
o.a.c.thrift.CassandraDaemon.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-971) simplify configuration file loading
[
https://issues.apache.org/jira/browse/CASSANDRA-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13023638#comment-13023638
]
Oleg Tsvinev commented on CASSANDRA-971:
I see PropertyConfigurator still there, as of version 0.7.4.
public abstract class AbstractCassandraDaemon implements CassandraDaemon
{
//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.);
}
---PropertyConfigurator.configureAndWatch(configLocation.getFile(), 1);
org.apache.log4j.Logger.getLogger(AbstractCassandraDaemon.class).info(Logging
initialized);
}
private static Logger logger =
LoggerFactory.getLogger(AbstractCassandraDaemon.class);
simplify configuration file loading
---
Key: CASSANDRA-971
URL: https://issues.apache.org/jira/browse/CASSANDRA-971
Project: Cassandra
Issue Type: Improvement
Components: Core
Reporter: Jonathan Ellis
Assignee: Jonathan Ellis
Priority: Minor
Fix For: 0.7 beta 1
Attachments: 971.txt
Currently we can load the configuration file from (a) a full path specified
by -Dstorage-config, or (b) storage.conf.xml located anywhere on the
classpath (filename may not be changed).
I think we should figure out what The Right Thing is to do here, and then do
it, instead of trying multiple guesses in an effort to prevent ... what?
ISTM that the java idiom here is, look for a default filename on the
classpath, and allow customizing that name w/ a system property, but when
taking the property ONLY the filename is customized, not the full path. This
is what log4j does, for instance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of FAQ by MakiWatanabe
Dear Wiki user, You have subscribed to a wiki page or wiki category on Cassandra Wiki for change notification. The FAQ page has been changed by MakiWatanabe. The comment on this change is: Update #seed. http://wiki.apache.org/cassandra/FAQ?action=diffrev1=116rev2=117 -- seed to contact. Once a node join the ring, it learns about the other nodes, so it doesn't need seed on subsequent boot. - There is no special configuration for seed node itself. In stable and - static ring, you can point non-seed node as seed on bootstrap though + #In stable and static ring, you can point non-seed node as seed on bootstrap though - it is not recommended. + #it is not recommended. + + If you configure a node as seed, it doesn't auto_bootstrap. So if you want to add a node to ring and make it seed, auto_bootstrap first, and then make it seed next. Anchor(seed_spof)
[jira] [Commented] (CASSANDRA-2549) Start up of 0.8-beta1 on Ubuntu
[ https://issues.apache.org/jira/browse/CASSANDRA-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024652#comment-13024652 ] Eric Evans commented on CASSANDRA-2549: --- The cql jar is not a dependency here. If it needs to be packaged, it's something that would get its own package. Start up of 0.8-beta1 on Ubuntu Key: CASSANDRA-2549 URL: https://issues.apache.org/jira/browse/CASSANDRA-2549 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8 beta 1 Environment: Linux home.broadley.org.nz 2.6.32-29-generic-pae #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC 2011 i686 GNU/Linux Reporter: Drew Broadley Labels: start Fix For: 0.8.0 Attachments: cassandra-0.8.0beta1-debian-package.patch root@home:/home/drew# cassandra -f INFO 14:06:03,261 Logging initialized INFO 14:06:03,323 Heap size: 1543831552/1543831552 INFO 14:06:03,332 JNA not found. Native methods will be disabled. INFO 14:06:03,379 Loading settings from file:/etc/cassandra/cassandra.yaml INFO 14:06:03,899 DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard ERROR 14:06:04,028 Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.init(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.init(MBeanSupport.java:136) at com.sun.jmx.mbeanserver.StandardMBeanSupport.init(StandardMBeanSupport.java:64) at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:174) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516) at org.apache.cassandra.service.StorageService.init(StorageService.java:231) at org.apache.cassandra.service.StorageService.clinit(StorageService.java:171) at org.apache.cassandra.locator.DynamicEndpointSnitch.init(DynamicEndpointSnitch.java:78) at org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:429) at org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:294) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:98) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.thrift.UnavailableException at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) ... 23 more Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.init(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.init(MBeanSupport.java:136) at
[jira] [Commented] (CASSANDRA-2464) Distributed test for read repair
[ https://issues.apache.org/jira/browse/CASSANDRA-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024664#comment-13024664 ] Pavel Yaskevich commented on CASSANDRA-2464: LGTM, but maybe it's better to replace Thread.sleep(1); with following changes - replace client to needsrepair node and make repeating read with interval in like 3 secs with consistency level ONE? Distributed test for read repair Key: CASSANDRA-2464 URL: https://issues.apache.org/jira/browse/CASSANDRA-2464 Project: Cassandra Issue Type: Test Reporter: Stu Hood Assignee: Stu Hood Labels: test Fix For: 0.8.1 Attachments: 0001-Distributed-test-for-read-repair.txt See title. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CASSANDRA-2552) ReadResponseResolver Race
ReadResponseResolver Race
-
Key: CASSANDRA-2552
URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Assignee: Stu Hood
Fix For: 0.8.0
When receiving a response, ReadResponseResolver uses a 3 step process to decide
whether to trigger the condition that enough responses have arrived:
# Add new response
# Check response set size
# Check that data is present
I think that these steps must have been reordered by the compiler in some
cases, because I was able to reproduce a case where the condition is not
properly triggered:
{noformat}
INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
in 2 messages
INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514 ReadResponseResolver.java
(line 87) post append for 1087367065: hasData=true in 1 messages
INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
Read timeout: java.util.concurrent.TimeoutException:
ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
{noformat}
The last line shows that both results were present, and that one of them was
holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2549) Start up of 0.8-beta1 on Ubuntu
[ https://issues.apache.org/jira/browse/CASSANDRA-2549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024702#comment-13024702 ] Jonathan Ellis commented on CASSANDRA-2549: --- But from the stacktrace, the thrift jar is a dependency, no? Start up of 0.8-beta1 on Ubuntu Key: CASSANDRA-2549 URL: https://issues.apache.org/jira/browse/CASSANDRA-2549 Project: Cassandra Issue Type: Bug Components: Packaging Affects Versions: 0.8 beta 1 Environment: Linux home.broadley.org.nz 2.6.32-29-generic-pae #58-Ubuntu SMP Fri Feb 11 19:15:25 UTC 2011 i686 GNU/Linux Reporter: Drew Broadley Labels: start Fix For: 0.8.0 Attachments: cassandra-0.8.0beta1-debian-package.patch root@home:/home/drew# cassandra -f INFO 14:06:03,261 Logging initialized INFO 14:06:03,323 Heap size: 1543831552/1543831552 INFO 14:06:03,332 JNA not found. Native methods will be disabled. INFO 14:06:03,379 Loading settings from file:/etc/cassandra/cassandra.yaml INFO 14:06:03,899 DiskAccessMode 'auto' determined to be standard, indexAccessMode is standard ERROR 14:06:04,028 Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.init(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.init(MBeanSupport.java:136) at com.sun.jmx.mbeanserver.StandardMBeanSupport.init(StandardMBeanSupport.java:64) at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:174) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:330) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:516) at org.apache.cassandra.service.StorageService.init(StorageService.java:231) at org.apache.cassandra.service.StorageService.clinit(StorageService.java:171) at org.apache.cassandra.locator.DynamicEndpointSnitch.init(DynamicEndpointSnitch.java:78) at org.apache.cassandra.config.DatabaseDescriptor.createEndpointSnitch(DatabaseDescriptor.java:429) at org.apache.cassandra.config.DatabaseDescriptor.clinit(DatabaseDescriptor.java:294) at org.apache.cassandra.service.AbstractCassandraDaemon.setup(AbstractCassandraDaemon.java:98) at org.apache.cassandra.service.AbstractCassandraDaemon.activate(AbstractCassandraDaemon.java:314) at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:80) Caused by: java.lang.ClassNotFoundException: org.apache.cassandra.thrift.UnavailableException at java.net.URLClassLoader$1.run(URLClassLoader.java:217) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java:321) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:266) ... 23 more Exception encountered during startup. java.lang.NoClassDefFoundError: org/apache/cassandra/thrift/UnavailableException at java.lang.Class.getDeclaredMethods0(Native Method) at java.lang.Class.privateGetDeclaredMethods(Class.java:2444) at java.lang.Class.privateGetPublicMethods(Class.java:2564) at java.lang.Class.getMethods(Class.java:1427) at com.sun.jmx.mbeanserver.MBeanAnalyzer.initMaps(MBeanAnalyzer.java:126) at com.sun.jmx.mbeanserver.MBeanAnalyzer.init(MBeanAnalyzer.java:116) at com.sun.jmx.mbeanserver.MBeanAnalyzer.analyzer(MBeanAnalyzer.java:104) at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.getAnalyzer(StandardMBeanIntrospector.java:66) at com.sun.jmx.mbeanserver.MBeanIntrospector.getPerInterface(MBeanIntrospector.java:181) at com.sun.jmx.mbeanserver.MBeanSupport.init(MBeanSupport.java:136) at
[jira] [Updated] (CASSANDRA-2552) ReadResponseResolver Race
[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stu Hood updated CASSANDRA-2552:
Description:
When receiving a response, ReadResponseResolver uses a 3 step process to decide
whether to trigger the condition that enough responses have arrived:
# Add new response
# Check response set size
# Check that data is present
I think that these steps must have been reordered by the compiler in some
cases, because I was able to reproduce a case for a QUORUM read where the
condition is not properly triggered:
{noformat}
INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
in 2 messages
INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514 ReadResponseResolver.java
(line 87) post append for 1087367065: hasData=true in 1 messages
INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
Read timeout: java.util.concurrent.TimeoutException:
ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
{noformat}
The last line shows that both results were present, and that one of them was
holding data.
was:
When receiving a response, ReadResponseResolver uses a 3 step process to decide
whether to trigger the condition that enough responses have arrived:
# Add new response
# Check response set size
# Check that data is present
I think that these steps must have been reordered by the compiler in some
cases, because I was able to reproduce a case where the condition is not
properly triggered:
{noformat}
INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
in 2 messages
INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514 ReadResponseResolver.java
(line 87) post append for 1087367065: hasData=true in 1 messages
INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
Read timeout: java.util.concurrent.TimeoutException:
ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
{noformat}
The last line shows that both results were present, and that one of them was
holding data.
ReadResponseResolver Race
-
Key: CASSANDRA-2552
URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Assignee: Stu Hood
Fix For: 0.8.0
When receiving a response, ReadResponseResolver uses a 3 step process to
decide whether to trigger the condition that enough responses have arrived:
# Add new response
# Check response set size
# Check that data is present
I think that these steps must have been reordered by the compiler in some
cases, because I was able to reproduce a case for a QUORUM read where the
condition is not properly triggered:
{noformat}
INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
in 2 messages
INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
in 1 messages
INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
Read timeout: java.util.concurrent.TimeoutException:
ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
{noformat}
The last line shows that both results were present, and that one of them was
holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2552) ReadResponseResolver Race
[
https://issues.apache.org/jira/browse/CASSANDRA-2552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13024705#comment-13024705
]
Stu Hood commented on CASSANDRA-2552:
-
I have a patch ready that I believe fixes this: testing it out before posting.
ReadResponseResolver Race
-
Key: CASSANDRA-2552
URL: https://issues.apache.org/jira/browse/CASSANDRA-2552
Project: Cassandra
Issue Type: Bug
Components: Core
Reporter: Stu Hood
Assignee: Stu Hood
Fix For: 0.8.0
When receiving a response, ReadResponseResolver uses a 3 step process to
decide whether to trigger the condition that enough responses have arrived:
# Add new response
# Check response set size
# Check that data is present
I think that these steps must have been reordered by the compiler in some
cases, because I was able to reproduce a case for a QUORUM read where the
condition is not properly triggered:
{noformat}
INFO [RequestResponseStage:15] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=false
in 2 messages
INFO [RequestResponseStage:8] 2011-04-25 00:26:53,514
ReadResponseResolver.java (line 87) post append for 1087367065: hasData=true
in 1 messages
INFO [pool-1-thread-54] 2011-04-25 00:27:03,516 StorageProxy.java (line 623)
Read timeout: java.util.concurrent.TimeoutException:
ReadResponseResolver@1087367065(/10.34.131.109=false,/10.34.132.122=true,)
{noformat}
The last line shows that both results were present, and that one of them was
holding data.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
