• New Feature
  • Status: Closed
  • 3 Minor
  • Resolution: Won't Fix
  • steve
  • Reporter: drb
  • November 30, 2006
  • 0
  • Watchers: 1
  • July 27, 2012
  • February 17, 2007


Mode allowed for applications nodes (L1s) to continue to function as standalone web containers if they lose connection to the Terracotta Server (L2).


* Just for Sessions
* Should it timeout before disconnected mode kicks in
* Application nodes can swap objects in and out, and only load a configured portion of each session, and configure the L1s accordingly.
* Exception thrown is application attempts to accesses to shared object not in the application node (L1) DSO cache.
* Queue up DSO transactions (L1 mutates an object that's already in its local DSO cache).
* Upon reconnect, what happens? Meaning of <client-reconnect-window>.
* Allow dirty reads?

Virtual Router Redundancy Protocol (VRRP): http://en.wikipedia.org/wiki/Virtual_router_redundancy_protocol


Ron Bodkin 2007-01-17

I find that if I the L2 server stops then an L1 Web application (like the Spring JMX sample app) will hang, even if you restart the L2. This results in losing threads in the app server and might also result in deadlock. Apparently a network outage would cause this too. It would be very desirable to support recovery from lost connections and even server crashes.

Steve Harris 2007-01-17

Are you running in persistent mode?

Ron Bodkin 2007-01-17

This isn’t in persistent mode. I will test that case…

Steve Harris 2007-01-17

In persistent mode you can bring down the server, which should pause things that require locks, when the server comes back up things should continue

Ron Bodkin 2007-01-17

It works in persistent mode thanks for clarifying that. This is a way I can test monitoring slow Terracotta performance with Glassbox :-)

Saravanan Subbiah 2007-01-24

If CDV-97 is implemented this might not be needed.

Saravanan Subbiah 2007-02-17

Decided to do CDV-97