Improving zero downtime deployment support on capistrano
Improving zero downtime deployment support on capistrano
bin/torquebox - use `unzip` if `jar` is unavailable

The jar command is only packaged in the JDK, which may not be available
on the target system. Use the unzip command when jar is not available.
Update to JRuby 1.7.10 (TORQUE-1193)
Try to bypass CloudBees maven mirror
Fix the check for Capistrano 2 to work with our specs
Run finalizers after the zero downtime specs
Don't create so many unneeded JRuby runtimes in the zero downtime specs
Fix bad boolean logic on restart-all zero downtime spec
Merge pull request #173 from shawnjgoff/unzip

bin/torquebox - use `unzip` if `jar` is unavailable
Only create Sessions in ServletStore if needed (TORQUE-1198)

Previously we created a new Java HttpSession on every request when our
ServletStore was used, and now we only create a new one when data gets
written to the store.
Add ci-settings.xml to workaround bees proxy flakiness
Looks like jboss nexus has some invalid maven-metadata.xml, so try to workaround it
One more attempt to get maven on CI resolving artifacts correctly
Bump up to polyglot w/ Infinispan 6 for TORQUE-1199

The file cache store in Infinispan 6 is drastically faster than that
of Infinispan 5 with passivation disabled (our default). This means
the default configuration for our clustered session store is faster to
create/update sessions.
Try switching jboss public repos to workaround broken upstream maven
Remove locking from the request path with shared pools (TORQUE-1200)

This removes several sources of locking that were present in the
request path with shared pools - locking when borrowing / returning
Ruby runtimes, locking inside JRuby from initializing RubyIO
instances, and locking from JRuby when retrieving the JRubyClassLoader.

With these changes I see about a 50% improvement in top-end
performance for basic Rack apps. Most applications won't see this
performance boost, since our locking probably wasn't the bottleneck,
but for high-throughput and high-concurrency users this should speed
things up nicely.
Remove potential race condition from rake_spec integration test
Merge pull request #168 from razenha/master

Improving zero downtime deployment support on capistrano
Let the JBoss clustered session manager handle session expiration (TORQUE-1201)

Expiring keys behind the clustered session manager's back in
Infinispan leads to early session timeouts and in certain conditions
errors upon restarting a clustered TorqueBox.

This change also removes the default expiration (of less than 2
minutes) for regular Infinispan cache keys, instead relying on Ruby
clients to specify a cache expiration when adding entries.