[jira] [Created] (CASSANDRA-2848) Make the Client API support passing down timeouts
Make the Client API support passing down timeouts - Key: CASSANDRA-2848 URL: https://issues.apache.org/jira/browse/CASSANDRA-2848 Project: Cassandra Issue Type: Improvement Reporter: Chris Goffinet Priority: Minor Having a max server RPC timeout is good for worst case, but many applications that have middleware in front of Cassandra, might have higher timeout requirements. In a fail fast environment, if my application starting at say the front-end, only has 20ms to process a request, and it must connect to X services down the stack, by the time it hits Cassandra, we might only have 10ms. I propose we provide the ability to specify the timeout on each call we do optionally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[Cassandra Wiki] Update of "HowToContribute" by JonathanEllis
Dear Wiki user, You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification. The "HowToContribute" page has been changed by JonathanEllis: http://wiki.apache.org/cassandra/HowToContribute?action=diff&rev1=38&rev2=39 Comment: link "cassandra codebase" talk and ccm - 1. Read the relevant parts of ArchitectureInternals + 1. Read the relevant parts of ArchitectureInternals; watching http://www.channels.com/episodes/show/11765800/Getting-to-know-the-Cassandra-Codebase will probably also be useful 1. Check if someone else has already begun work on the change you have in mind in the [[https://issues.apache.org/jira/browse/CASSANDRA|issue tracker]] 1. If not, create a ticket describing the change you're proposing in the issue tracker 1. Check out the latest version of the source code @@ -11, +11 @@ * Verify that you follow Cassandra's CodeStyle. * Verify that your change works by adding a unit test. * Make sure all tests pass by running "ant test" in the project directory. + * For testing multi-node behavior, https://github.com/pcmanus/ccm is useful 1. When you're happy with the result create a patch: * svn add * svn diff > branchname-issue.txt (e.g. trunk-123.txt, cassandra-0.6-123.txt)
[jira] [Commented] (CASSANDRA-2688) Support wide rows with Hadoop support
[ https://issues.apache.org/jira/browse/CASSANDRA-2688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059146#comment-13059146 ] Jonathan Ellis commented on CASSANDRA-2688: --- related: CASSANDRA-2474 > Support wide rows with Hadoop support > - > > Key: CASSANDRA-2688 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2688 > Project: Cassandra > Issue Type: Improvement >Reporter: Jeremy Hanna > Labels: hadoop > > Currently the Hadoop support can only operate over the maximum row width of > thrift afaik. Then a user must do paging of the row within their hadoop > interface - java, pig, hive. It would be much nicer to have the hadoop > support page through the row internally, if possible. Seeing that one of > cassandra's features is extremely wide rows, it would be nice feature parity > so that people didn't have to adjust their cassandra plans based on hadoop > support limitations. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2805) Clean up mbeans that return Internal Cassandra types
[ https://issues.apache.org/jira/browse/CASSANDRA-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059144#comment-13059144 ] Jonathan Ellis commented on CASSANDRA-2805: --- If you can list which methods to clean up, this would be a good ticket for the surprisingly frequently asked, "What's a good place to get my feet wet in the Cassandra code?" > Clean up mbeans that return Internal Cassandra types > > > Key: CASSANDRA-2805 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2805 > Project: Cassandra > Issue Type: Bug >Affects Versions: 0.8.1 >Reporter: Nick Bailey >Assignee: Nick Bailey >Priority: Minor > Fix For: 0.8.2 > > > We need to clean up wherever we return internal cassandra objects over jmx. > Namely CompactionInfo objects as well as Tokens. There may be a few other > examples. > This is bad for two reasons > 1. You have to load the cassandra jar when querying these mbeans, which sucks. > 2. Stuff breaks between versions when things are moved. For example, > CASSANDRA-1610 moves the compaction related classes around. Any code querying > those jmx mbeans in 0.8.0 is now broken in 0.8.2. (assuming those moves stay > in the 0.8 branch) > For things like CompactionInfo we should just expose more mbean methods or > serialize to something standard like json. > I'd like to target this for 0.8.2. Since we've already broken compatibility > between 0.8.0 and 0.8.1, I'd say just fix this everywhere now. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2790) SimpleStrategy enforces endpoints >= replicas when reading with ConsistencyLevel.ONE
[ https://issues.apache.org/jira/browse/CASSANDRA-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059145#comment-13059145 ] Jonathan Ellis commented on CASSANDRA-2790: --- Ivan, did you get a chance to try the 2129 patch? > SimpleStrategy enforces endpoints >= replicas when reading with > ConsistencyLevel.ONE > > > Key: CASSANDRA-2790 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2790 > Project: Cassandra > Issue Type: Bug > Components: Core >Affects Versions: 0.7.6 > Environment: Linux 2.6.32-31-generic #61-Ubuntu SMP / Java > HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode) >Reporter: Ivan Gorgiev > > We use replication factor of 3 across our system, but in a one case on the > application bootstrap we read a stored value with a local (in-process) call > to StorageProxy.read(commands, ConsistencyLevel.ONE). This results in the > following exception from SimpleStrategy: "replication factor 3 exceeds number > of endpoints 1". > Shouldn't such a read operation always succeed as there is a guaranteed > single Cassandra endpoint - the one processing the request? > This code used to work with Cassandra 0.6.1 before we upgraded to 0.7.6. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059141#comment-13059141 ] Jonathan Ellis commented on CASSANDRA-2388: --- Sounds good, thanks! > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059136#comment-13059136 ] Mck SembWever commented on CASSANDRA-2388: -- the new "one-liner" CASSANDRA-2388 attached. i'll "submit patch" once i've tested it some... > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated CASSANDRA-2388: - Attachment: CASSANDRA-2388.patch > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mck SembWever updated CASSANDRA-2388: - Attachment: (was: CASSANDRA-2388-local-nodes-only.rough-sketch) > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059134#comment-13059134 ] Mck SembWever commented on CASSANDRA-2388: -- The idea is to setup splits to have only endpoints that are valid trackers. But now i see this is just a brainfart :-) Ofc the jobTracker will apply this match for us. And that CFIF was always 'restricted' to running on endpoints. Although the documentation on inputSplit.getLocations() is a little thin as to whether this restricts which trackers it should run on or whether is just a recommendation... I guess it doesn't matter, as you point out Jonathan all that's required here is the one line changed in CFRR. > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388-local-nodes-only.rough-sketch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CASSANDRA-2388) ColumnFamilyRecordReader fails for a given split because a host is down, even if records could reasonably be read from other replica.
[ https://issues.apache.org/jira/browse/CASSANDRA-2388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059134#comment-13059134 ] Mck SembWever edited comment on CASSANDRA-2388 at 7/2/11 10:08 PM: --- The idea is to setup splits to have only endpoints that are valid trackers. But now i see this is just a brainfart :-) Ofc the jobTracker will apply this match for us. And that CFIF was always 'restricted' to running on endpoints. Although the documentation on inputSplit.getLocations() is a little thin as to whether this restricts which trackers it should run on or whether is just a preference... I guess it doesn't matter, as you point out Jonathan all that's required here is the one line changed in CFRR. was (Author: michaelsembwever): The idea is to setup splits to have only endpoints that are valid trackers. But now i see this is just a brainfart :-) Ofc the jobTracker will apply this match for us. And that CFIF was always 'restricted' to running on endpoints. Although the documentation on inputSplit.getLocations() is a little thin as to whether this restricts which trackers it should run on or whether is just a recommendation... I guess it doesn't matter, as you point out Jonathan all that's required here is the one line changed in CFRR. > ColumnFamilyRecordReader fails for a given split because a host is down, even > if records could reasonably be read from other replica. > - > > Key: CASSANDRA-2388 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2388 > Project: Cassandra > Issue Type: Bug > Components: Hadoop >Affects Versions: 0.7.6, 0.8.0 >Reporter: Eldon Stegall >Assignee: Jeremy Hanna > Labels: hadoop, inputformat > Fix For: 0.7.7, 0.8.2 > > Attachments: 0002_On_TException_try_next_split.patch, > CASSANDRA-2388-addition1.patch, CASSANDRA-2388-local-nodes-only.rough-sketch, > CASSANDRA-2388.patch, CASSANDRA-2388.patch, CASSANDRA-2388.patch > > > ColumnFamilyRecordReader only tries the first location for a given split. We > should try multiple locations for a given split. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1125) Filter out ColumnFamily rows that aren't part of the query
[ https://issues.apache.org/jira/browse/CASSANDRA-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059114#comment-13059114 ] Jonathan Ellis commented on CASSANDRA-1125: --- Like Mck said, that will have to be split into another ticket, since it continues to depend on CASSANDRA-1600. > Filter out ColumnFamily rows that aren't part of the query > -- > > Key: CASSANDRA-1125 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1125 > Project: Cassandra > Issue Type: New Feature > Components: Hadoop >Reporter: Jeremy Hanna >Assignee: Mck SembWever >Priority: Minor > Fix For: 1.0 > > Attachments: 1125-formatted.txt, CASSANDRA-1125.patch > > > Currently, when running a MapReduce job against data in a Cassandra data > store, it reads through all the data for a particular ColumnFamily. This > could be optimized to only read through those rows that have to do with the > query. > It's a small change but wanted to put it in Jira so that it didn't fall > through the cracks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-1125) Filter out ColumnFamily rows that aren't part of the query
[ https://issues.apache.org/jira/browse/CASSANDRA-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059098#comment-13059098 ] Jeremy Hanna commented on CASSANDRA-1125: - So does this only include key ranges - that's what it sounds like. And indexes are out for now too, it sounds like - e.g. where timebucket = 12345. > Filter out ColumnFamily rows that aren't part of the query > -- > > Key: CASSANDRA-1125 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1125 > Project: Cassandra > Issue Type: New Feature > Components: Hadoop >Reporter: Jeremy Hanna >Assignee: Mck SembWever >Priority: Minor > Fix For: 1.0 > > Attachments: 1125-formatted.txt, CASSANDRA-1125.patch > > > Currently, when running a MapReduce job against data in a Cassandra data > store, it reads through all the data for a particular ColumnFamily. This > could be optimized to only read through those rows that have to do with the > query. > It's a small change but wanted to put it in Jira so that it didn't fall > through the cracks. -- 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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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] [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-tabpanel&focusedCommentId=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
