We're extremely excited to announce the immediate availability of TorqueBox 2.1.1! This is mostly a bug-fix release, with a few small features slipped in. It is a recommended upgrade for anyone running TorqueBox 2.x.
- Download TorqueBox 2.1.1 (ZIP)
- Browse HTML manual
- Browse JavaDocs
- Browse Gem RDocs
- Download PDF manual
- Download ePub manual
Highlights of major changes
The JRuby runtime pools for the various subsystems (web, messaging, jobs, services, stomp) can now be toggled between eager or lazy startup. Eager pools will start when the application is deployed while lazy pools will wait until they are needed (first web request comes in, first job fires, first message received) before booting. The web runtime defaults to eager and the rest to lazy. This is the same defaults as 2.1.0, but now you have the option of changing those defaults. See the pooling documentation for more details.
There was a rather nasty bug where message processors and jobs were sharing a single instance of the message processor or job class when running in production mode with the default shared pooling. This has been fixed and every incoming message gets a new message processor instance and every job that fires gets a new job instance.
TorqueBox will now serve files created by Rails page caching with our efficient static resource servlet vs cached page requests hitting the JRuby layer.
Rolling deployments when load-balancing behind mod_cluster are now easier since we don't tell mod_cluster that a web application is ready until it's actually ready to serve requests. Previously we told mod_cluster the application was ready before the JRuby runtime had actually booted which led to long delays or timeouts on the first requests to hit the newly deployed application.
Anyone using TorqueBox::Backgroundable with backgroundable methods that took longer than 5 minutes to complete has probably seen various errors in their logs related to the Arjuna library and transactions. To fix these errors, Backgroundable no longer runs inside an XA transaction by default. If you were relying on the transactionality of backgrounded methods, then you'll need to wrap the code inside your backgrounded method in a
TorqueBox.transactionblock as shown in the comments of TORQUE-906.
Upgrading from 2.1.0
Our goal with 2.1.1 was to be backwards-compatible with 2.1.0, so there shouldn't be any special steps needed for the upgrade. None of the underlying AS7 xml configuration files or torquebox.yml / torquebox.rb files need any changes. The only caveat is if you were relying on Backgroundable's transactionality, as mentioned above.
We're still sticking to our monthly release schedule so expect TorqueBox 2.1.2 (bug fixes only) to come out at the end of September followed by TorqueBox 2.2.0 (new features galore) at the end of October. As always the most up-to-date roadmap is available in JIRA.
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.1.0
- [TORQUE-420] - Allow job classes to have a on_error method that we call when the job raises
- [TORQUE-433] - Support Rails 3.1 Streaming Http Responses
- [TORQUE-542] - Log the environment AS7 is booting in when calling `torquebox run`
- [TORQUE-629] - stomp.yml causes Torquebox to fire a Warn: DEPLOYMENTS IN ERROR: Deployment "torquebox.StompServer" is in error
- [TORQUE-820] - Don't tell mod_cluster an app is deployed until web context is started
- [TORQUE-824] - Torquebox should support rails page cache conventions out of the box
- [TORQUE-852] - Processor and Service initialization receive a java Map
- [TORQUE-858] - Infinispan throws errors when a symbol is used as a key
- [TORQUE-865] - Enable eager/lazy initialization option per subsystem (jobs, messaging, etc)
- [TORQUE-881] - Rails 3.2 Tagged Logging support
- [TORQUE-882] - expose web context to rails applications
- [TORQUE-900] - Rails template should not break an application when running in a non-torquebox context
- [TORQUE-902] - Documentation/example for clustering mod_cluster without multicast is invalid and fails.
- [TORQUE-903] - Message Processors and Jobs are not threadsafe in production mode
- [TORQUE-906] - Long-running backgroundable tasks cause the Arjuna reaper to retry
- [TORQUE-907] - Support all the JEE transaction attributes, not just requires_new
- [TORQUE-909] - TorqueBox dies on "--client" option in JRUBY_OPTS
- [TORQUE-911] - Let receive optionally yield message to a block
- [TORQUE-912] - Can't background task with NewRelic installed
- [TORQUE-916] - torquebox.org/documentation/LATEST should point to 2.x docs, not 1.x