Red Hat
Jul 15, 2013
by The Entire TorqueBox Team

After months of hard work and 325 commits from 18 contributors we're proud to announce the first beta release of TorqueBox 3.0.0! This release introduces a much smaller TorqueBox download along with many other substantial changes, which we've highlighted below.

What is TorqueBox?

TorqueBox is a Ruby application server built on JBoss AS7 and JRuby. It supports Rack-based web frameworks and provides simple Ruby interfaces to standard enterprisey services, including scheduled jobs, caching, messaging, and services.

Highlights of changes in 3.0.0.beta1

Smaller download and lighter footprint

The standard TorqueBox binary distribution has been slimmed down from 147mb to 61mb! The runtime footprint is also reduced - expect about a 20mb reduction in memory usage with the same applications deployed to TorqueBox 3.0.0.beta1 compared to 2.3.2.

The downside to all this slimming is that you can no longer run Java EE applications (but can run regular Java .war files) in the standard slim download. You'll need to overlay TorqueBox on top of JBoss EAP 6 (see below) if you deploy Java EE applications that utilize CDI, EJBs, MDBs, or pretty much any other enterprise-sounding three letter acronym. If you just use Ruby and the occasional .war file that will run on servers like Apache Tomcat then the slim download is all you need.

Overlay for JBoss Enterprise Application Server 6

If you use Java EE then you'll need to download JBoss EAP 6, our new TorqueBox overlay for EAP 6, and unzip the TorqueBox overlay on top of EAP 6. We've added a new section to the Getting Started Guide to walk you through this process.

The TorqueBox EAP overlay is purely additive and does not modify any existing files when unzipped on top of a JBoss EAP 6 installation. Because of this, if you boot EAP 6 via standalone.sh instead of torquebox run, you'll need to tell EAP where to find the TorqueBox config files:

standalone.sh --server-config=torquebox-full.xml    # standalone
      standalone.sh --server-config=torquebox-full-ha.xml # standalone clustered
      domain.sh --server-config=torquebox-full.xml        # domain mode
      

Zero downtime deployments

The ability to redeploy an application to TorqueBox without losing any web requests was our most requested feature ever. And, with TorqueBox 3, we've added that and more! You can now redeploy an entire application or just pieces of an application (web, messaging, jobs, etc) without downtime. See the new Zero Downtime Redeployment section of our user manual for all the details.

More runtime control of jobs and messaging

We've exposed several new Ruby API methods to let you schedule jobs (including new 'at'-style jobs), change a message processor's concurrency setting, and expire or move messages between queues all at runtime. If you haven't looked in a while, now would be a good time to review our Ruby API docs. Specifically those for TorqueBox::ScheduledJob, TorqueBox::Messaging::MessageProcessor, TorqueBox::Messaging::MessageProcessorProxy, and TorqueBox::Messaging::Queue.

Ruby 2.0 and Rails 4 support

We now support Ruby 2.0 and Rails 4 to the extent that JRuby does. You'll need to use activerecord-jdbc-adapter 1.3.0.beta2 or newer with Rails 4 - rails new won't automatically pick this version for new applications.

If you want to try the combination of Rails 2.0 and Rails 4, you'll need to add a workaround for a Struct#to_h bug present in JRuby 1.7.4 - see commit 5fc4da428f1d122a2c29ad3ea675b4cf1bc27565 for an example.

Resource injection completely overhauled

Previously, to use resource injection, we used to ask users to include TorqueBox::Injectors followed by fetch(...). We've now deprecated that usage in favor of TorqueBox.fetch, without the need to include anything into your classes. The old inject(...) method from TorqueBox::Injectors was completely removed, since it was deprecated in previous TorqueBox 2 releases.

We've also moved all injection work to happen at runtime, getting rid of the previous behavior of scanning Ruby source files before application deployment. Any configuration related to injection being enabled or not or configuring the injection paths we scan is now obsolete, and applications with large numbers of source files may notice a substantial improvement in deployment speed.

Messaging (HornetQ) clustering changes

We've upgraded to a newer version of HornetQ that now clusters via JGroups for simplified clustering configuration. Whether in a multicast or non-multicast environment the JGroups section of the AS7 configuration file now gets used for all clustering. This is especially helpful when configuring clustering in non-multicast environments like Amazon EC2.

Other important changes

See the individual issues linked below for more details on each of these items.

Upgrading from 2.3.2

Upgrading from 2.3.2 to 3.0.0.beta1 should be fairly smooth - please let us know.

  • If you deployed Java EE applications to TorqueBox you'll need the new EAP overlay as described above.

  • If you were still using TorqueBox::Injectors.inject that method was removed - switch to TorqueBox.fetch instead.

  • If you managed the underlying AS7 configuration files yourself, quite a few things have changed in TorqueBox 3. Take a moment to diff the new configuration files against any existing ones. For the slim distribution, standalone.xml, standalone-ha.xml, and domain.xml (in domain mode) are what get used. For the EAP overlay, torquebox-full.xml, torquebox-full-ha.xml, and torquebox-full.xml (in domain mode) are what get used.

Don't be a stranger!

As always, if you have any questions about or issues with TorqueBox, please get in touch.

Issues resolved since 2.3.2

  • [TORQUE-257] - Provide support for 'at' jobs
  • [TORQUE-470] - Synchronous Message Processors
  • [TORQUE-591] - Don't create a new connection only to re-use the currently active session
  • [TORQUE-674] - Allow runtime scheduling of jobs
  • [TORQUE-764] - Ability to accomplish anything that can be done in torquebox.yml via API that can be used dynamically at runtime
  • [TORQUE-795] - Allow changing processors' concurrency setting without restarting torquebox or redeployment of an app
  • [TORQUE-804] - Expand clustering documentation with example output
  • [TORQUE-819] - Allow zero downtime deploy of specific Ruby runtimes
  • [TORQUE-860] - Allow to deploy Message Processors and Jobs stopped
  • [TORQUE-877] - fix support for remote message processors
  • [TORQUE-887] - rake torquebox:freeze doesn't generate the vendor/bundle/jruby/ tree under rails 3.2
  • [TORQUE-929] - Automatically close ActiveRecord connections when finished with work in non-web threads
  • [TORQUE-941] - cached ruby hash is invalid after tb deploy
  • [TORQUE-959] - expose the message_ttl for backgroundable futures
  • [TORQUE-996] - Mention non-activerecord use of JDBC in documentation
  • [TORQUE-1004] - Document how to enable sendfile support in TorqueBox
  • [TORQUE-1006] - Unable to use symbols to fetch session data
  • [TORQUE-1013] - Expose session configuration options
  • [TORQUE-1014] - Inconsistency in Rails session store and cache store names.
  • [TORQUE-1017] - torquebox relies on AS71, but hornetq bridge relies on AS7.2
  • [TORQUE-1019] - Upgrade to AS 7.2 / EAP 6.1 compatible builds
  • [TORQUE-1022] - Capistrano support should use sudo to start/stop torquebox service in initd control style
  • [TORQUE-1023] - Capistrano support could let users deploy the application with a name other than the :application option
  • [TORQUE-1024] - TorqueBox session store should index by String too
  • [TORQUE-1025] - expose expireMessage, sendToDeadLetterQueue, and moveMessage methods
  • [TORQUE-1027] - Poorsmatic shouldn't "rescue Exception"
  • [TORQUE-1030] - Create a core codecs lib used by both messaging and caching
  • [TORQUE-1033] - Create messaging objects with a default :encoding
  • [TORQUE-1034] - Re-enable container-managed JAAS authorization
  • [TORQUE-1039] - Update Remote JMX connection documentation
  • [TORQUE-1042] - Have destination deployment create a global MSC service
  • [TORQUE-1047] - Move all injection work to happen at runtime instead of a pre-deployment scanner
  • [TORQUE-1051] - 'torquebox rails' command doesn't work with Rails 4
  • [TORQUE-1053] - Use QueueInstaller to create queues using TorqueBox::Messaging::Queue.start method
  • [TORQUE-1054] - Remove TorqueBox::Injectors deprecated inject method
  • [TORQUE-1056] - Add TorqueBox.fetch(...) method as alternative to including TorqueBox::Injectors
  • [TORQUE-1059] - Increase default messaging and jobs pool size in development mode
  • [TORQUE-1061] - Db connection leak between deploy
  • [TORQUE-1067] - Missing depednencies errror while replacing scheduled job
  • [TORQUE-1069] - Make it possible to create queues and topic at runtime in the way they are created currently at boot time
  • [TORQUE-1070] - Infinispan::Cache created with a persist option causes encoding errors
  • [TORQUE-1073] - Marshaling error with cache store
  • [TORQUE-1075] - Use service name in :inspect implementation
  • [TORQUE-1079] - Always reconfigure caches when created, regardless of replication mode
  • [TORQUE-1080] - Expose :max_entries and :eviction options for caches
  • [TORQUE-1087] - Servlets defined in WEB-INF/web.xml are ignored
  • [TORQUE-1088] - Documentation missing for clustering without multicast for jgroups-diagnostics
  • [TORQUE-1089] - Substantially decrease size of torquebox-server gem
  • [TORQUE-1090] - Improper assigning of the name instance variable in TorqueBox::Messaging::Queue and Topic when using the javax.jms.Destination as the destination
  • [TORQUE-1095] - Create Slim TorqueBox Based on Custom AS 7.2 Builds
  • [TORQUE-1101] - Make hornetq use jgroups for clustering
  • [TORQUE-1108] - UTF-8 strings become MacRoman on OS X when JVM runs under Apple JDK
  • [TORQUE-1113] - Add Ruby 2.0 Support
  • [TORQUE-1115] - Support Rails 4 applications