Joe Satriani Guitar Clinic

My son and I got to see an incredible guitar clinic put on by Joe Satriani at Sweetwater on March 27th. Was a great time! He played a lot of the Surfing album, and discussed the theory behind the songs.

Some of the videos I was able to get from my cell phone are posted on my YouTube channel.

Converting Ruby/Rails JMS to JRuby/Glassfish/OpenMQ

I have been working lately on trying to get the existing stack - which is a Ruby on Rails app utilizing ActiveMessaging with ActiveMQ via Stomp - and getting it to work completely within a Glassfish JRuby container, using JMS and OpenMQ instead.

It has been challenging for sure, but am making progress little by little. I will be posting any progress I make soon after I get some of the issues ironed out.

Some of the issues I am working on include:

• Converting current separate daemonized pollers that are the message queue listeners into either jruby pollers or separate jruby classes that run in the same VM as the main app itself (as opposed to running a separate 'jruby' call of some sort).
• Getting the messaging.rb/broker.yml to use jms and jndi lookups for the ConnectionFactories.
• How to use/register OSGi bundles in the environment so that they can be queried and monitored.
• Converting existing component/plugins from a combination of java component (which use sysjava as daemon wrappers) and ruby components into OSGi bundle plugins.
• Many more... :)

 I will update the solutions as they are worked through.

JDBC/JNDI Pooling with a JRuby/Rails app

In working on the transition of this rails app over to the JRuby/Glassfish camp, one of the things I needed to take advantage of was using jdbc/jndi database pooling and configurations.

Of course, using rails, the application was using ActiveRecord for it's DB/ORB interactions, and in researching, the steps needed to get this setup were:

1. Create the JDBC connection pool
2. Create the resource with a JNDI name
3. Update the database.yml
4. Configure ActiveRecord for disconnects

I also needed to download and put the postgresql jdbc driver in place ($domain/lib/ext/ - using the JDBC version 4 driver).

In looking at the jdbc templates included with Glassfish (glassfish/lib/install/templates/resources/jdbc), I attempted to use the template for my driver (postgresql_type4_datasource.xml). This was causing issues using the 'url' property, so ended up using asadmin to create, using serverName and databaseName as properties.

Starting up the asadmin interactive utility:

asadmin> create-jdbc-connection-pool
--datasourceclassname org.postgresql.ds.PGConnectionPoolDataSource
--restype  javax.sql.ConnectionPoolDataSource
--property user=XXX:password=XXX:serverName=localhost:databaseName=extension_dev extensionDevPool

Command create-jdbc-connection-pool executed successfully.
asadmin> create-jdbc-resource --connectionpoolid extensionDevPool jndiExtensionDev

Command create-jdbc-resource executed successfully.
asadmin> list-jdbc-connection-pools
__TimerPool
DerbyPool
extensionDevPool

Command list-jdbc-connection-pools executed successfully.

asadmin> list-jdbc-resources
jdbc/__TimerPool
jdbc/__default
jndiExtensionDev

Command list-jdbc-resources executed successfully.

asadmin> ping-connection-pool extensionDevPool

Command ping-connection-pool executed successfully.

I created separate pools/resources for dev/test/production - which will be commented accordingly for now in the domain.xml file.

Next came setting up the database.yml file to use jndi instead of the regular ActiveRecord drivers. There are some excellent resources on the web for getting this done, but had to do some digging to get this correct.

One of the issues in setting this up correctly was, that especially during development and testing, we are using the jruby console (jruby -S script/console) to create and activate objects and events, which in turn looks at the database.yml file to get its connection.

This was hurting me because once set to use jndi, none of these settings were setup correctly and I would continue to get connection issues as well as the jms missing class issues.

So, to fix, in the database.yml file, we not only test for the RAILS_ENV to be java (or the JRUBY_VERSION to be set), but we needed to test to see if we were in a servlet context (ala Glassfish) as well as to use jndi based connections or regular connections.

So, our database.yml file ended up looking like:

defaults: &defaults
<% jdbc = defined?(JRUBY_VERSION) ? 'jdbc' : '' %>
<% if defined?($servlet_context) %>
adapter: jdbc
driver: org.postgresql.Driver
<% else %>
adapter: <%= jdbc %>postgresql
<% end %>
username: xxx
password: xxx
host: localhost

development:
<% if defined?($servlet_context) %>
jndi: jndiExtensionDev
<% end %>
database: extension_dev
<<: *defaults

test:
<% if defined?($servlet_context) %>
jndi: jndiExtensionTest
<% end %>
database: extension_test
<<: *defaults

production:
<% if defined?($servlet_context) %>
jndi: jndiExtensionProd
<% end %>
database: extension_prod
<<: *defaults

This enabled us to access the db in our app as well as run the console and connect correctly.

We now need to configure ActiveRecord to disconnect after every query - which was not needed before since we are now using JDBC to manage the connection persistence. (See resources below for links to some of the sites that were used to research all of this).

# config/initializers/close_connections.rb
if defined?($servlet_context)
require 'action_controller/dispatcher'

ActionController::Dispatcher.after_dispatch do
    ActiveRecord::Base.clear_active_connections!
end
end

Some of the excellent resources I used:

• Arun Gupta's Blog
• LinkedIn Blog: JDBC Connection Pooling for Rails on Glassfish
• Nick Sieger's RailsConf 2008 Preso
• Syntatic: Connection Pooling for Rails/Ruby using JNDI/JDBC

RoR App to run under JRuby

After deciding on the platform, one of the big things to get accomplished was getting the current application to run inside a JRuby container inside Glassfish.

This was a bit challenging at first, and it still isn't all quite there, but the main core of the app is now running in there, with a few changes.

We are not deploying via a war file (yet) - since we are just building this, but deploying as a directory (for development) from my git workspace to build up the configuration steps.

There were quite a few challenges (and more to come) - some of which were based on the gem compatibilities between ruby and jruby - more notably libxml and libxslt - which rely on native libraries.

Before I got here, this was tackled a little bit by another engineer here, Rich, who created an xml_lib.rb that wrapped what we needed via the libxml and libxslt libraries to utilize their java counterparts - so that was a big boost for this process.

We will probably replace those with more robust ones if we need in the future, but this library works great for what we are using it for at the moment. There is a port of libxml-ruby called libxml-jruby, written by Dylan Vaughn, which will do what we need - and we will probably pull out the XSLT functions that Rich wrote and separate the lib this way.

A big part of this was getting the correct gems installed and being used for jruby, and adjustments in the configurations for the current app to separate what to load if running under jruby as opposed to ruby.

Example - in 'conf/environment.rb' - the config gems were separated out:

if RUBY_PLATFORM =~ /java/
config.gem 'jdbc-postgres', :lib => 'jdbc/postgres'
config.gem 'activerecord-jdbc-adapter', :lib => 'jdbc_adapter'
config.gem 'activerecord-jdbcpostgresql-adapter',
      :lib => 'active_record/connection_adapters/jdbcpostgresql_adapter'
else
config.gem 'pg', :version => '0.8.0'
config.gem 'libxml-ruby', :lib => 'xml/libxml', :version => '1.1.3'
config.gem 'libxslt-ruby', :lib => 'libxslt', :version => '0.9.2'
end

After installing and setting up Glassfish with a new domain and installing jruby, needed to make the jruby container available to Glassfish:

% asadmin create-domain --adminport 4848 extension
...
...
Command create-domain executed successfully.

% asadmin configure-jruby-container --jruby-home=/usr/local/jruby

and then deployed my current app (being in the parent dir of the rails app directory)

% asadmin deploy --property jruby.rackEnv=development core/

Starting my domain here, I was able to access the app successfully via the context of the app name (http://localhost:8080/core/). Adding 'context-root="/"' to the <application ... section allowed me to access without adding '/core/' to my URL.

Notice the setting of:

--property jruby.rackEnv=development

This is basically the equivalent of setting RAILS_ENV=development in your environment.

Next step was getting the db to work with jdbc/jndi pooling.

*Note: One issue I was having was the complaining of missing the class javax.jms.MessageListener:

/usr/local/jruby/lib/ruby/site_ruby/shared/builtin/javasupport/core_ext/object.rb:37:
in `get_proxy_or_package_under_package':
NameError: cannot load Java class javax.jms.MessageListener

Following the directions on http://wiki.glassfish.java.net/Wiki.jsp?page=OpenMQJRuby, I created and moved the appropriate jms/imq jar files to my domain/lib/ext directory and these are no longer an issue. I will have to see why this was when I work with the MQ issues (and converting from ActiveMQ to OpenMQ).

1. .../mq/lib/jms.jar
2. .../mq/lib/imq.jar
3. .../mq/lib/imqjmsra.jar

imqjmsra.jar is created by extracting it from imqjmsra.rar:

jar xvf imqjmsra.rar imqjmsra.jar

Move these into the domain/lib/ext directory. These will also need to be included in your classpath when using the jruby console.

Deciding on a platform

One of the tasks in this new role was to determine which platform to take this application/appliance to. We knew it was to move towards a Java/JEE platform, but we needed to make sure what we were choosing was right for the long term, and had the most viability for expansion and technology.

I have worked with many app servers/web containers in the past, and definitely had my mind on what I wanted to work with, but used the time to research as many alternatives as I could to make sure the conclusion was the right one.

The way this application works, we are relying on being able to plug in new "interfaces" that the core application can talk to - via JMS messaging, etc. The application is built using RoR (Ruby on Rails) with a Postgresql backing store.

Clustering and HA were of a concern as well, but the type of clustering that this application requires was beyond the scope of the normal web/http traffic type clustering that is solved via mod_jk or mod_cluster type solutions - although this can help for certain aspects of it.

JVM-level clustering - such as Terracotta - was also an option, but that didn't really solve what we were looking for as a turn-key solution either - so the decision here is to create our own custom solution, using what was available as a basis for the types of clustering that was needed for that type of traffic. Creating an observer of our JMS cloud(s) to peer for relevant information (via JMX hooks) such as acceptable load thresholds and speaking to other nodes to open/start new modules as need to offset the load.

This is going to be a challenge, but a welcome one. :)

I definitely wanted to utilize the OSGi concepts in creating the daemon like plugins that we would be using, as well as using the framework for monitoring activity, so having that capability was a big factor in the decision making. I looked at other modularity solutions, such as JPF (Java Plugin Framework) and Impala, as well as what Project Jigsaw would bring to the table, but decided OSGi would do well for what we needed.

There were many containers that were looked at, including:

• Glassfish v2 and v3
• JBoss 5 and JBoss 6 (M2)
• Geronimo
• WebSphere
• Weblogic
• resin

and others. The final decision for me boiled down to Glassfish v3 and JBoss 6, because of the JEE6 specifications and where they were headed.

So going forward, we will be building this platform using Glassfish v3 - which is exciting to me, because I always thought Glassfish was a great platform, and coming from the NAS world of old, it was great to see where this was going.

Clustering is a bit of an issue that will need to be tackled, but in reading Bill Shannon's roadmap for clustering in v3.1 of Glassfish, as well as needing to build our own, this was not as much of a deal breaker as I was worried about.

The current application also uses ActiveMessaging to communicate with an ActiveMQ server, and with Glassfish's embedded OpenMQ based messaging system, I think the ability to have as much as we can under one container is a big win in this situation.

Thanks to the support of the Glassfish community, and people such as Arun, Alexis, the Glassfish team (blog and twitter) and the others involved, I think using this going forward is going to a fun and exciting project!

New Adventures (so long Sun, hello Extension)!

It has been a long time since I blogged about anything, but with new events that have happened recently, I figured now was as good a time as any!

On January 29th, 2010, I was laid off from Sun Microsystems, where I enjoyed an almost 13 year career. Being bought out by Oracle was going to be an exciting time. I thought we (or I) were going to see a resurgence of the Sun of old. It was a great adventure, and I learned quite a lot, as well as worked with a number great of people, so it was sad to leave.

I did a great number of things while in Sun, including working on the installation environment for Solaris 8 and Solaris 9, creating the installation kiosk for CD0, co-founding the BigAdmin portal (which lived in the installation kiosk, and which stayed with me for 10 years, up until my last day), worked on the sysid suite of tools, ereg, iChange jumpstart application, customized CMS applications and more.

But that being said, I am ready for new challenges and to move onto something new.

On February 22, 2010, I started working for a new company, Extension, Inc., which is developing a health-care communication appliance that has a lot of potential. Sounds very challenging, and involves a lot of research and development which will result in a very compelling product in a field that is very open to new technology right now.

Being in Sun for so many years, I am very used to working under pressure, and getting to develop in some of the latest technologies, and that will continue in my new role (as Sr. Software Engineer), which I am very grateful for.

My new role will involve a lot of Java/JEE development, utilizing Glassfish 3 (awesome!) as well as digging into Ruby/JRuby, and building on the Ubuntu platform to begin with.

So, my first entries here will involve the work I have been doing and will be doing on converting an existing Rails application to work inside of a JRuby container inside of Glassfish 3, the trials involved in that, converting ruby components into OSGi compliant Java modules, and building a solid communication platform for many different devices from within a health-care environment.