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
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.
* fix incorrect context-param parsing and only configure logging whendeployment 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 thejruby_compat_version configuration option)* allow arbitrary keys to be stored with Trinidad::Configuration* changed Trinidad::Lifecycle::Base to be a (ruby-like) base lifecycle listenerskeleton 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 applicationsrunning 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 viathe 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