Unweaving the Rainbow

Ehcache for JRuby and Rails: Now with more flavor and fewer calories

2010-11-15T10:35:00.000-08:00

In my last blog post I discussed how you can achieve Terabyte scale for JRuby and Rails, and judging from the response I received this is a topic of some interest to Ruby and Rails developers. In that post I explained how it is possible to use Ehcache as a Rails caching provider, or use its API directly from any JRuby application. Since that time, I've done some further work to make Ehcache integration with JRuby and Rails more robust and production ready. In this post I'll describe what's new and improved, including complete coverage of the Ehcache Java API. In a followup post I will discuss how to utilize the new Ehcache JRuby and Rails integration for large scale enterprise applications, including fully coherent distributed caching with Ehcache and Terracotta, and also how to use BigMemory for Enterprise Ehcache to make sure your application can handle any load you can throw at it.

More Flavor

In previous iterations of jruby-ehcache we took the approach of providing Ruby wrapper classes to encapsulate the functionality of Ehcache behind a nice Ruby interface. This had the advantage of making the API more idiomatic to Ruby, but it also meant that we did not provide full API coverage and that any time the Ehcache API changed we also had to update our Ruby wrapper API to accommodate the changes. As you can imagine, we weren't entirely satisfied with this approach and so went in search of a better mechanism. It turns out that JRuby's Java integration combined with Ruby's dynamic open classes provide exactly what we need for this.

The Java integration provided by JRuby makes it incredibly easy to use any Java API from Ruby code. All that is required is adding a simple require 'java' to your Ruby code and the whole of the Java landscape is opened up to you. We built on top of this in the latest jruby-ehcache gem by having the gem automatically set up the CLASSPATH and invoke require 'java'for you, and now with one line of code you instantly have the complete Ehcache API available to your Ruby application:

require 'ehcache'

With that one line of code in place, you can now use any part of the Ehcache API just as you would in a Java application, and JRuby even provides some extra niceties to make the Java API more Ruby-friendly:

require 'ehcache'
  cache_manager = Java::NetSfEhcache::CacheManager.new
  cache = cache_manager.getCache("myCache")
  cache.put("answer", "42")
  answer = cache.get("answer")  # Returns Ehcache Element object
  puts "Answer: #{answer.value}"
  question = cache.get("question") # Returns nil
  if question
    puts "Question: #{question.value}"
  else
    puts "I don't know the question"
  end

I won't cover every detail of JRuby Java integration (see Calling Java From Ruby on the JRuby wiki for full details), but I do want to point out a couple of important details. First, notice how Java classes are referenced from Ruby code. The expression Java::NetSfEhcache::CacheManager is a reference to the Java class net.sf.ehcache.CacheManager. More generally, any Java class can be accessed within the Java module by transforming the package path by removing the dots and converting to CamelCase. Second, JRuby performs some magic to convert Java method names and JavaBeans property accessors to more Ruby-like equivalents. Thus, you can call the getCache method in any of three ways: getCache, get_cache, or simply cache.

That is nice enough, but as any good Rubyist will attest, Java APIs tend to be bloated and difficult to use compared to an equivalent Ruby API. Luckily, we can take advantage of Ruby's dynamic nature and support for open classes to provide a much more Rubyesque API without sacrificing full access to the underlying Java API. For instance, it would be nice if we could use the familiar array access notation to access cache entries, and while we're at it couldn't we also do away with the Ehcache Element object and just access the cache entry value directly? Let's see how this is done.

class Java::NetSfEhcache::Cache
    # Gets an element value from the cache.  Unlike the #get method, this method
    # returns the element value, not the Element object.
    def [](key)
      element = self.get(key)
      element ? element.value : nil
    end
  end

  # Later...
  forty_two = cache['answer']   # Returns the value, not the Element object

Here we open up the net.sf.ehcache.Cache class and add our own custom method to it to provide array access notation. Note that this is not inheritance and we are actually modifying the Cache class directly, so you can now use the [] operator on any Cache object, whether you created it yourself in Ruby code or it was created deep in the bowels of some legacy Java code. The world is yours.

Another bit of Ruby goodness we've added in the latest version is to make the Ehcache::CacheManager and Ehcache::Cache classes include the Ruby Enumerable module. Anyone who's done a significant amount of Ruby programming knows how powerful this module is, but for those who might not be familiar with it let's have a look at a few example usages that illustrate it's power.

# Find all cache entries with time to live greater than one minute.
  cache.find_all {|e| e.ttl > 60}

  # Which cache entry has the largest time to live value?
  cache.max {|e1, e2| e1.ttl <=> e2.ttl}

  # Are all cache entries strings?
  cache.all? {|e| e.value.is_a?(String)}

  # Does cache contain the ultimate question of life, the universe, and everything?
  cache.any? {|e| e.name == 'The Ultimate Question'}

  # Sum of all numeric cache entries.
  cache.inject(0) {|sum, e| e.value.is_a?(Numeric) ? sum + e.value : sum}

  # Find the email address of creators of inferior programming languages
  cache.reject {|e| e.value == 'Ruby'}.map {|e| e.value.creator_email}.uniq

This is just a small preview of what Ruby's Enumerable provides. For full reference, see the documentation on ruby-doc.org. Be aware that if you have a large cache, this kind of iteration over every element could be prohibitively expensive, but for smaller caches it provides a very powerful querying mechanism. For large caches, there is a new search API for Ehcache currently in the works, which uses indexing for efficient searching and will be available in an upcoming Ehcache release.

There are several other ways in which the Ruby API has been enhanced but I can't describe all of them here. If you're curious, see the RDoc API documentation that is bundled with the jruby-ehcache gem. And, of course, because the full Java API is available to you, you can also use the Ehcache Javadocs for reference.

Fewer Calories

In addition to adding the above features, we've also done some fat trimming for this latest release. First and foremost, we have deprecated the YAML configuration option in favor of using the Ehcache native XML configuration. We know that some Rubyists will be disappointed by this decision ("What? More XML?"), but we feel it was the right decision for several reasons:

The YAML configuration code is by far the most complicated bit of code in the Ehcache JRuby integration and we feel that it is a likely source of bugs.
YAML configuration is handled by pure Ruby code, and the Ehcache Java code is completely ignorant of it. Any time that there is a change to the Ehcache configuration format, it would require an update and new release to the Ruby YAML code, meaning that we'd be playing a continual catch-up game with Ehcache core.
There are subtle differences between the YAML configuration and the XML configuration that we feel can only lead to confusion in the long run.
Java developers who already use Ehcache will already have ehcache.xml configuration files that they can now use directly instead of translating to YAML.

While we're talking about configuration, I should mention that we've made some improvements to how your configuration files are located. Previous versions of jruby-ehcache required that you place a config.yml file in your $HOME/lib/config directory, which of course made it less than practical to have more than one application using jruby-ehcache at any given time. With version 1.0.0 you have a lot more options available to you. Now you can put your ehcache.xml either in the same directory as the Ruby file that creates the CacheManager object, or place it in your Java CLASSPATH, or you can specify any location in your call to the CacheManager constructor. If you are using Rails, then ehcache.xml will continue to reside in the canonical Rails config directory.

Finally, we've removed a limitation that prevented you from using versions of Ehcache other than that bundled with the jruby-ehcache gem, and made it easy to drop in Enterprise Ehcache JARs into your application. With the latest updates, jruby-ehcache will use your Java CLASSPATH to locate the Ehcache JARs it should use, instead of forcing the use of the bundled Ehcache. In my next blog post I will discuss how you can take advantage of this to add BigMemory to your application, or utilize distributed caching with Terracotta for linear scale out.

How to Improve Battery Life for the Samsung Epic 4G

2010-10-23T11:41:00.000-07:00

I recently purchased a new Android phone, the Samsung Epic 4G from Sprint, and I love almost everything about it. However, when I first started using the phone battery life was absolutely horrendous. Even with light usage I was unable to make it through a full day on a single charge and I often had to plug the phone in and charge it several times per day. Now, though, I've done some research and experimentation and am happy to report that not only does my phone make it through the whole day on a single charge, but I also have upwards of 40% battery remaining when I go to bed at night. Now I can let the kids play Angry Birds without fear of my phone dying.
This post will explain how you too can achieve good battery life for your Samsung Epic or other Android phone, and do so without sacrificing the functionality you've come to depend on. (Note: while much of the advice in this blog post is specific to the Samsung Epic, there are some general strategies that apply to any Android phone, so you may find something of interest even if you do not own an Epic.)

A Note About Task Killers and Other Ineffective Practices

If you read a typical forum post from a poor user suffering from battery life problems, the post will usually start out with frustrated pleadings like

I've tried everything! I turn off Wi-Fi, live wallpaper, and use Advanced Task Killer to kill all running apps and services, but nothing works! Help!

Usually the helpful people trying to answer such pleadings offer further advice about turning off GPS and Bluetooth, or reducing screen brightness and timeout. While these techniques can provide incremental improvements to battery life, they do so at the cost of functionality of your phone. I do personally keep Bluetooth disabled when I'm not using it, but always leave wifi and GPS enabled (GPS does not consume any power just by being enabled, only when an app is actively using it). And of course, 4G data connections are known to be a serious battery hog so you probably don't want to leave that on all the time.
Automatic task killers, though, are most likely doing more harm than good and I do not recommend using them. Android manages tasks and processes quite well on its own and automatic task killers interfere with Android's normal mode of operation. Any time a process is killed, it means that it will consume more power next time it needs to be started. Furthermore, many of the tasks that are killed by these auto task killers are important components of your phone's functionality and having them killed in the background is only crippling your phone. I do keep a task killer app on my phone, but only use it when I suspect that an application is misbehaving, and can then individually kill the suspect app. Never let an automatic task killer indiscriminately kill apps or services in the background; doing so is just shooting yourself in the foot.
With that little lecture out of the way, let's look at some practices that are effective at enhancing battery life.

Disable the DRM Service

The Samsung Epic (and presumably other Samsung Galaxy S class phones) come with the Media Hub application for viewing movies and television programs. While this may some day address a gap in the Android platform, as it stands today the Media Hub application offers only a very limited set of programs for rent or purchase. Worse yet, though, the DRM service that comes with the application is a severe power hog. The biggest battery boosting technique you can perform for the Epic is to disable this service altogether.
To disable the DRM service, start from your Android home screen and then go to:

Menu → Settings → Applications → Running services

Once there you should see an entry for the Samsung DRM service. Click on this entry to disable the service, and voilà, you instantly have better battery life.

(Note: while you are there, take a look around and see if there are other services running that you do not need. I disabled a couple of other services on my phone, namely the Aloqa widget update service, and the SportsTap widget service since I don't use either of these widgets.)

You may come to find that this service spontaneously springs back to life. You could occasionally repeat this process and stop the service whenever you notice it is running, but why would you want to do that when your phone can do it for you? To permanently kill this service you can use a startup auditing application to make sure that it doesn't reincarnate. I installed the Startup Auditor app, which is a paid application but there are free apps that offer similar functionality. With Startup Auditor I was able make sure that the DRM service did not start automatically at boot time, and furthermore would never spontaneously start itself at all.

	Startup Auditor Free A boot monitor and startup monitor tool which displays a list of applications you may disable. Free version supported by ads.
	Startup Auditor A boot monitor and startup monitor tool which displays a list of applications you may disable. Full version eliminates ads and can disable unlimited.

Note that the Media Hub application probably will not function if you've disabled the DRM service. I do not personally use this app so this is no loss for me.

The Airplane Mode Toggle Trick

One of the biggest drains on a mobile phone battery is when there is a weak signal and the cellular radio frequently scans for a signal. Not much can be done about this when reception truly is weak or there is no signal whatsoever. However, there is an insidious bug in the current Epic firmware that "tricks" the phone into thinking it does not have a signal, and causing the power drain while the phone is scanning for a good signal&emdash;even though it already has one!
You can tell if you are affected by this bug by checking your battery usage:

(Menu) → Settings → About phone → Battery use → Cell standby

On this screen you will see a line that reads "Time without a signal". If you've been in a good coverage area but the percentage on this line is high (say 50% or so) then you are suffering from the bug described previously.
Now, how to fix it? Until Samsung or Sprint provides us with an update, there is a simple trick that works around this bug. All you have to do is put your phone in airplane mode. Hold down the power button on your phone until the pop-up menu appears and then select Airplane mode. Wait approximately 15 seconds, then repeat the process to take your phone back out of airplane mode. For reasons that are not clear to anyone, this airplane mode toggle will prevent the false weak signal bug and the battery drain that goes along with it.
One important thing to note is that this workaround does not survive a power cycle. You will need to repeat this process every time you restart your phone.

Prevent Wi-Fi Sleep

An oft-cited bit of advice is to disable wi-fi to preserve battery power. While this may be true for who are not frequently connected to wi-fi or who spend most of their time on the road, it is actually counter productive if you are usually within range of a wi-fi access point. This is because an active 3G connection consumes more power than an active wi-fi connection. To make matters worse, though, Android's default settings for wi-fi sleep policy are suboptimal. The default setting is to disconnect from wi-fi whenever the screen timeout has been reached, and this in turn causes a 3G data connection to activate. When you turn your phone screen back on your phone will then reconnect to wi-fi. This cycle of wi-fi off → 3G on → 3G off → wi-fi on consumes significant amounts of power. It would be better to leave the wi-fi connection active regardless of the state of the screen. You can do this by changing the wi-fi sleep policy:
(Menu) → Settings → Wireless & networks → Wi-Fi settings → (Menu) → Advanced → Wi-Fi sleep policy
Change the setting to Never. I work from home and am therefore usually in range of my wireless router. I speak from experience when I say that this change can make a significant difference in battery life.
What about the road warriors among you, though? If you are typically out and about and not always connected to a wi-fi access point, changing the global Wi-Fi sleep policy will probably prove detrimental, as your phone will constantly keep scanning for wi-fi connections even when it is otherwise sleeping. Fear not, there is a solution for you too, at least if you don't mind paying for the overall excellent Locale app and installing a couple of very useful plugins. Here is what you will need:

	Locale A powerful app allowing you to create situations and apply settings and other actions when the situation is active
	KeepWiFi Locale A Locale plugin that keeps wi-fi enabled when active
	Locale Wifi Connection Plugin A Locale Plug-in that allows you to set a condition based on what wifi network you're connected to, instead of within range of

With these tools in hand, here is how you can construct a Locale situation that keeps wi-fi enabled when you are connected to a preferred network, but then reverts to the default Android sleep policy when not connected to this network. (First, if you have already followed the above steps to set your sleep policy to Never, you should now set it back to the default value of When screen turns off.)

Open Locale.
Create a Defaults situation if you do not already have one.
Go into the Defaults situation.
Push Add Setting.
Push Keep WiFi.
Leave the value for KeepWiFi Service as Off, then use the back button on your phone to go back.
Save the Defaults situation (Menu → Save).
Push Add Situation.
Enter a name for the situation (I named mine after my home wi-fi network).
Push Add Condition.
Choose Wifi Connection.
Enter the SSID of your wi-fi network, the use the back button on your phone to go back.
Push Add Setting.
Choose Keep WiFi.
This time change the KeepWiFi Service value to On, then use the back button on your phone to go back.
Finally, save the new situation (Menu → Save).

Now whenever you are connected to your preferred wi-fi network, the wi-fi connection will be kept active, preserving power by not switching to 3G data connection. When you are not connected to this network the default wi-fi sleep policy will be used, preserving power by not constantly scanning for wi-fi networks even when the phone screen is off. Locale allows you to have the best of both worlds.

Other Miscellaneous Tips

The following are more well-known tips for extending battery life and since most people are probably already aware of them I don't feel I need to expound upon them very much, but I include them here for reference.

Disable 4G data connections whenever not actually in use.
Uninstall any apps that you do not use and do not plan to use.
Limit the frequency of background sync for things like Facebook, Twitter, email, etc.

Terabyte Scale for JRuby and Rails

2010-10-21T13:03:00.000-07:00

In this, my inaugural blog post, I'm going to explain how you can use Ehcache and Terracotta from your JRuby and Rails applications. Ehcache is the most popular open source caching solution in the Java landscape and Terracotta's Enterprise Ehcache provides the ultimate in scalability allowing you to store over a terabyte of data in a fully coherent cache. And now you can use it to provide unprecedented levels of scale to the Rails world.

A Little Bit of History

I work at Terracotta and one of the fun things we do there is to have a semi-annual "dev week", during which the whole distributed team gathers together in our San Francisco office to collaborate in person. During our last dev week we had a product improvement competition and my entry into the competition was a set of Ruby Gems to provide integration between Ehcache and JRuby/Rails. To do this, I built on top of the work done by Dylan Stamat, who originally created the JRuby Ehcache integration. As with so many other open-source projects maintained by people in their free time, this project had been lying dormant for some time while Dylan was busy with other obligations. I decided to pick up where Dylan left off and as a result of this there is a new set of Ruby Gems for working with Ehcache from JRuby, Rails 2, and Rails 3.

Caching in Rails has traditionally been done using memcached, either directly using the Memcache API or using the Rails caching API with a memcached backend. While this has worked fairly well for most people, there are some limitations to memcached that have led some to seek alternative solutions. If you limit yourself to solutions that work with the standard C implementation of Ruby ("Matz's Ruby Implementation") then memcached is likely your best bet. However, if you are able to use JRuby, a whole new universe of caching solutions emerges, now including the very popular Ehcache.

Using Ehcache with JRuby

Ehcache JRuby integration is provided by the jruby-ehcache gem. To install it simply execute:

jgem install jruby-ehcache

Ehcache configuration is done with the ehcache.yml YAML file. The jruby-ehcache gem includes a default ehcache.yml file, but if you would like to customize it you can copy the ehcache.yml file bundled with the gem and place it in your $HOME/lib/config directory and then edit it as you see fit. (This is no longer true. See my blog post Ehcache for JRuby and Rails: Now with more flavor and fewer calories for information about recent changes.)

Now it is time to start using Ehcache. Let's take a look at a simple example that uses the Ehcache::CacheManager to create a cache, and then puts and gets some date in the cache.

require 'ehcache'

manager = Ehcache::CacheManager.new
cache = manager.cache

cache.put("answer", "42", {:ttl => 120})
answer = cache.get("answer")
puts "Answer: #{answer}"
question = cache.get("question") || 'unknown'
puts "Question: #{question}"

manager.shutdown

Save this code as "jruby-ehcache-demo.rb" and execute it as follows:

jruby -rubygems jruby-ehcache-demo.rb

As you can see from the example, you create a cache using CacheManager.new, and you can control the "time to live" value of a cache entry using the :ttl option in cache.put. Note that not all of the Ehcache API is currently exposed in the JRuby API, but most of what you need is available and we plan to add a more complete API wrapper in the future.

Using Ehcache in Rails Applications

To use Ehcache from a Rails application you must first install the correct gem for your Rails version.

jgem install jruby-ehcache-rails2 # for Rails 2
jgem install jruby-ehcache-rails3 # for Rails 3

Configuration of Ehcache is still done with the ehcache.yml file, but for Rails applications you must place this file in the config directory of your Rails app. Note that you must use JRuby to execute your Rails application, as these gems utilize JRuby's Java integration to call the Ehcache API.

With this configuration out of the way, you can now use the Ehcache API directly from your Rails controllers and/or models. You could of course create a new Cache object everywhere you want to use it, but it is better to create a single instance and make it globally accessible by creating the Cache object in your Rails environment.rb file. For example, you could add the following lines to config/environment.rb:

require 'ehcache'
EHCACHE = Ehcache::CacheManager.new.cache

By doing so, you make the EHCACHE constant available to all Rails-managed objects in your application. Using the Ehcache API is now just like the above JRuby example.

If you are using Rails 3 then you have a better option at your disposal: the built-in Rails 3 caching API. This API provides an abstraction layer for caching underneath which you can plug in any one of a number of caching providers. The most common provider to date has been the memcached provider, but now you can also use the Ehcache provider. Switching to the Ehcache provider requires only one line of code in your Rails environment file:

config.cache_store = :ehcache_store

A very simple example of the Rails caching API is as follows:

Rails.cache.write("answer", "42")
Rails.cache.read("answer")  # => '42'

Using this API, your code can be agnostic about the underlying provider, or even switch providers based on the current environment (e.g. memcached in development mode, Ehcache in production).

If you'd like to see a complete example of an Ehcache-enabled Rails application, check out this demo that I wrote to show Ehcache in action:

http://svn.terracotta.org/svn/forge/projects/ehcache-rails-demo/trunk

Conclusion

With Ehcache plugged into your Rails application you have a whole slew of options to address all of those Enterprisey concerns. With Terracotta's Enterprise Ehcache product you can have the ultimate in scalability by taking advantage of distributed caching or eliminating Java garbage collection pauses with BigMemory. Plug in a Terracotta Server Array behind your clustered Rails application and you can store hundreds of millions of keys in your cache, and over a terabyte of data.

If you'd like to use Rails for your web app but your boss has concerns about scalability, Ehcache might just be for you.

You can read further documentation on the Ehcache web site, or grab the source from GitHub.