Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I ended up doing the following:</p> <p>Both Tomcats are always started. The application is also started on both of the Tomcats.</p> <p>A special <code>synchronization service</code> was hand-written. This service is part of the application and started along with the application startup. It is responsible for determination of the node that is currently active and which one <em>should</em> be active.</p> <p>My application used a Spring context for managing my services lifecycle. I separated it into two different contexts: a <code>wrapper</code> Spring context and a <code>child</code> Spring context.</p> <p>The <code>wrapper</code> context was started along with the application startup, always available and working on both Tomcats. The synchronization service was configured as a bean in the <code>wrapper</code> context.</p> <p>The <code>child</code> context actually included all services that my application provided for external clients. <em>This</em> is the context that I designated to be started only when current node is active and stopped when becoming passive.</p> <p><strong>How was the <code>child</code> context swithched on / off when active / passive?</strong></p> <p>This context wasn't started automatically along the application startup. When the <code>synchronization service</code> concluded that the current node should become active, an event was raised that caused the <code>child</code> context to get started, thus making all services <em>available</em> on that node. And the other way around: when the <code>synchronization service</code> concluded that the current node shuold become passive, a proper event was raise that caused the <code>child</code> context to shutdown, making all services <em>unavailable</em> on that node.</p> <p>Another important feature that was added was an <code>interceptor</code> for incoming requests. An incoming request hitting the one of the Tomcats, actually implies that the load balancer / web server has decided that the target node <em>is the currently available or preferred node</em>. In such a case, even if it happened that the target node was the passive one, it <em>should</em> now become active. So the <code>intercepror</code> would raise the same event that the <code>synchronization service</code> did, again making the <code>child</code> context to start and the services available on that node (and the <code>synchronization serivce</code>s on both Tomcats identified the switch and the formerly active node would passivate).</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload