I’ve been working with the DataStax Enterprise 2.01 install for a bit now and it was working great until one day I was no longer able to get any queries to work using the cqlsh I was just getting the error that one or more nodes was unavailable. I tried restarting and still nothing would work I got a few errors in the logs (shown below).

I was able to quickly fix the error by removing my data directory and starting fresh as this is just my development environment that works great for me. You can find your data directory in the cassandra.yaml file ($DSE_HOME/resources/cassandra/conf/cassandra.yaml), look for the data_file_directories entry. Mine was set to /var/lib/cassandra/data so I just ran the following and started cassandra fresh and everything is back to working order.

rm -r /var/lib/cassandra/data

    INFO [JOB-TRACKER-INIT] 2012-12-28 10:32:32,515 JobTracker.java (line 2427) problem cleaning system directory: cfs:/tmp/hadoop-jeffbeck/mapred/system
    java.io.IOException: UnavailableException()
    	at com.datastax.bdp.hadoop.cfs.CassandraFileSystemThriftStore.listSubPaths(CassandraFileSystemThriftStore.java:1137)
    	at com.datastax.bdp.hadoop.cfs.CassandraFileSystem.listStatus(CassandraFileSystem.java:192)
    	at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2392)
    	at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2195)
    	at org.apache.hadoop.mapred.JobTracker.<init>(JobTracker.java:2189)
    	at org.apache.hadoop.mapred.JobTracker.startTracker(JobTracker.java:303)
    	at org.apache.hadoop.mapred.JobTracker.startTracker(JobTracker.java:294)
    	at org.apache.hadoop.mapred.HadoopTrackerPlugin$1.run(HadoopTrackerPlugin.java:230)
    	at java.lang.Thread.run(Thread.java:680)
    Caused by: UnavailableException()
    	at org.apache.cassandra.service.ReadCallback.assureSufficientLiveNodes(ReadCallback.java:212)
    	at org.apache.cassandra.service.StorageProxy.scan(StorageProxy.java:1083)
    	at org.apache.cassandra.thrift.CassandraServer.get_indexed_slices(CassandraServer.java:746)
    	at com.datastax.bdp.hadoop.cfs.CassandraFileSystemThriftStore.listSubPaths(CassandraFileSystemThriftStore.java:1120)
    	... 8 more

The grails release plugin is great for publishing plugins to grails central but it will also publish a plugin to a maven repo. You simple need to configure the new maven repo inside build config. But if you want to release snapshots to an internal maven but not have that config checked in publicly that is a bit more tricky. With a quick bit of code added to BuildConfig.groovy we can have it pull in the config from a file we can choose to not checkin. Now with our public code we don’t need to expose our internal login info. See the file changes below for an example.

Add this to BuildConfig.groovy:

    def mavenConfigFile = new File("${basedir}/grails-app/conf/mavenInfo.groovy")
    if (mavenConfigFile.exists()) {
    	def slurpedMavenInfo = new ConfigSlurper().parse(mavenConfigFile.toURL())
    	slurpedMavenInfo.grails.project.repos.each {k, v ->
    		println "Adding maven info for repo $k"
    		grails.project.repos."$k" = v
    	}
    }
    else {
    	println "No mavenInfo file found."
    }

Then you can create a file called mavenInfo.groovy:

    grails.project.repos.internalSnap.url = 'http://internal.com:8080/nexus/content/repositories/internal-snapshots/'
    grails.project.repos.internalSnap.username = 'fakeUser'
    grails.project.repos.internalSnap.password = 'fakePass123'

Grab the gist.

I am using a simple redirect after a user logs in so they can get to the page they were heading too the URLs were ending up with %2F in the url which caused a 404 error. The problem wasn’t actually in Grails at all but in the mod_rewrite rule being used to force HTTPS connection the rule was set up to end with [L,R] when to correctly deal with the url encoding we were already doing it needed to be [NE,L,R]

Reference: http://www.webmasterworld.com/apache/3279075.htm

When working with jQuery 1.6.1 and the jQuery Form Example Plugin I found that the examples were being serialized the plan was to use Ajax to send the serialized data back to the server and save it but I didn’t want to have to try and remove the examples server side. So triggering unload on the examples will allow serialize to get the correct data. Example JavaScript below.

    var examples = $('.example');
    _.each(examples,function(elm){
        $(elm).unload();
    });

I used Userscore.js to give me a quick foreach style loop and called the unload event on every element that has the class .example which is the default class that jQuery Form Example plugin uses.

So dealing with Datetime between client and server side can always be fun due to timezones but adding a number of browsers makes it all the more complicated. For our project we are using Joda-Time on the Java side and a mix of technologies on the client side (I will be addressing that soon). So we deiced to pass all datetimes via ISO-8601 the problem came when dealing with the different browsers. IE7 and IE8 both output a string that doesn’t have the milliseconds where Chrome and FireFox did.

On the Java side we used ISODateTimeFormat.dateTime() to parse the incoming date string so we wanted the milliseconds.

To make this work I made a quick JavaScript utility that I can use to output the correct format in UTC time as we wanted. You can see the code below.

Its rather simple just using the UTC versions of getting the date and time elements I construct a string that will be ISO-8601 formatted. I have tested this in IE 7, 8, and 9 Chrome and FireFox. If there are any issues feel free to comment and I will do what I can to help.