Trinidad 1.4.0 (San Fernando) released

55 views
Skip to first unread message

kares

unread,
Jul 24, 2012, 7:44:06 AM7/24/12
to rails-t...@googlegroups.com
 I'm happy to announce (once again :)) that Trinidad 1.4.0 has been released !

The most noticeable new features for users are a (hopefully) "leak" free hot deployment and better logging out of the box.
There seems to be still some issues with hot reloads, that seem to relate to Rails caching, they will hopefully get resolved soonish in a future 1.4.x release.
Two minor issues where fixes since the RC, no where directly related with the new code (they are likely to be present in the previous 1.3.x line as well).

Hot Deployment

Trinidad supports monitoring a file to reload applications, when the file tmp/restart.txt is updated (e.g. touch tmp/restart.txt), the server reloads the application the file belongs. The file monitor can be customized with the monitor configuration option.

Trinidad now supports 2 reload strategies :

  • restart (default) synchronous reloading (exposed by Tomcat). This strategy pauses incoming requests while it reloads the application and than serves them once ready (or timeouts if it takes too long). It has been chosen as the default strategy due it's more predictable memory requirements.

  • rolling "zero-downtime" (asynchronous) reloading strategy similar to Passenger's rolling reloads. This has been the default since 1.1.0 up till now. If you use this you should account that your JVM memory requirements might increase quite a lot since requests are being served while there's another version of your application getting loaded.

Configure the reload strategy per web application or globally e.g. :

---
  port: 8080
  environment: production
  reload_strategy: rolling


Logging

Trinidad continues to use standard output for server logs by default, it also prints warnings and error messages on error output, while application specific log messages (e.g. logs from Rails.logger) go into the expected file location at log/{environment}.log.

Application logging performs daily rolling out of the box (similar to Tomcat) and only prints messages from an application to the console while it runs in development mode, that means you won't see any application specific output on the console say in production !

Please note that these logging details as well as the logging format will be configurable with trinidad.yml/.rb within the next 1.4.x release.


We'll probably let the RC out for a week or two, to catch up possible incompatibilities with extensions as Trinidad's internal APIs have been polished,
some changes are not backwards compatible but most of the time we expect things to work just fine.

Please give it a spin and let us know, either here or report issues with https://github.com/trinidad/trinidad/issues

Here's the full change-log for reference :

* fix incorrect context-param parsing and only configure logging when
  deployment descriptor did not specified jruby.rack.logging param (#76)
* deep symbolize_options should account for arrays of hashes (#80)
* requires latest Tomcat 7.0.28 (jars 1.0.5) due context reloading fix
* requires latest jruby-rack 1.1.7 due delegating RackLogger to JUL
* Trinidad::WebApp API revisited some changes are non-backwards compatible !
* enable running multiple applications with different ruby versions (using the
  jruby_compat_version configuration option)
* allow arbitrary keys to be stored with Trinidad::Configuration
* changed Trinidad::Lifecycle::Base to be a (ruby-like) base lifecycle listener
  skeleton implementation, thus removed all web app specifics from the class
  (include Trinidad::Lifecycle::WebApp::Shared to gain the same functionality)
* removed unused Trinidad::Rack module and KeyTool from Trinidad::Tomcat
* reinvented server/application logging with Trinidad::Logging :
  - refactored Trinidad's global logging configuration with JUL
  - application logs into log/env.log by default with daily rolling
  - console logs are now less chatty and only print logs from applications
    running in development mode (configuration to come in a later release)
  - make sure Trinidad's custom log formatter prints thrown exceptions
  - use local timestamps with (file) log formatter by default
* Trinidad::Server#add_web_app for code re-use during rolling redeploys
* refactored application (monitor based `touch 'tmp/restart.txt'`) reloading
  - bring back synchronous context reloading and make it default
  - "zero downtime" async rolling reload is still supported and configurable via
    the reload_strategy: rolling configuration option
  - updated the context restart code - hot deploys should now work reliably (#75)
  - moved Trinidad::Lifecycle::Host under Trinidad::Lifecycle::WebApp::Host
  - Trinidad::Lifecycle::Host now accepts a server instance instead of a tomcat
  - introduced Trinidad::WebApp::Holder to be used instead of bare Hash
* add async_supported attribute for servlet (3.0) configuration

K.
Reply all
Reply to author
Forward
0 new messages