Application Server Solutions for Microsoft IIS and ASP.NET
       solutions   products   partners   company   support   downloads         store
ServletExec Self-Help: FAQ
Back to Search >  Back to Search Results

Faq ID 102
Product ServletExec
Category Miscellaneous
Question Can ServletExec be run in a multi-machine, HTTP Server Cluster?
Answer Yes, however at this time New Atlanta does not provide a standard solution for keeping the configuration files of the various distinct instances of ServletExec in sync with each other. Here are some specifics of the problem at hand:
If you deploy new Servlets or make other modifications to the ServletExec configuration on machine A, then machine B (separate machine with separately running instance of ServletExec) does not know about these changes. Even if you were to have both instances of SE (the one on machine A and the one on machine B) share the exact same ServletExec configuration files (on the same hard drive), the in-memory representation of the configuration for SE instance B would not be updated when you accessed the admin UI of SE instance A to make the changes. At this time we recommend the following approach to work around this architectural reality:
  1. Install ServletExec (must use SE AS) separately on each machine. (this requires a separate ServletExec license for each machine).
  2. Have each SE AS instance share the exact same Configuration files (have just one ServletExec Data folder). This would be done by editing the StartServletExec script for each SE instance to use the same value for the -home parameter.. Having more than 1 SE AS instance using the exact same configuration files (ServletExecData folder) is no longer recommended. You may deploy copies of the same .war file to each SE AS instance but sharing global configs such as application.xml, servletexec.xml, etc... between 2 or more SE AS instance can cause stability problems when 2 or more instances try to write to those files at the same time. In that scenario the problem may manifest in any of several different ways such as disappearing webapps, disappearing license keys, crashing JVMs, hanging requests, etc... and such problems may not be seen until some time later, making it very difficult to understand the cause.
  3. To synchronize the ServletExec config files between various distinct instances of ServletExec:
    Let's say that machine A has SE instance A which is the active instance and that machine B has SE instance B which is a passive instance. Whenever you use the SE admin UI for the active SE instance to make configuration changes, bounce the other SE instances (the ones that are up and running but not being used... "passive"). That will force them to read the new configuration files and thus pickup those changes.. Use the SE Admin UI for each SE AS instance to manually configure the changes you wish to mimick across all instances. For example... deploying identical, private copies of a .war file onto each SE AS instance (each instance gets its own separate copy of the .war file).
  4. To manage the synchronization of your own code between various SE instances, use a Web Application. When you change any code or settings within it, distribute the updated copy of your app to each of the SE AS instances (for example overwrite all the old myWebApp.war files with the new one). Then simply reload it dynamically from all the SE AS admin UIs of all your SE AS instances in the cluster. You could even write your own code that utilizes the AdminAPI class that is built into ServletExec. In this way your code could perform these kinds of dynamic reloads programatically. A working example of this sort of code can be found at: It is called WebAppReloader.

    NOTE: WebAppReloader is only an example of how one might use the AdminAPI of ServletExec, and it is not meant for use in production. Also, the use of ServletExec's AdminAPI is experimental and not officially supported.
  5. To manage session data between the various instances:
    • Beginning with SE 5.0, it is possible to setup multiple/redundant web applications each using the JdbcSessionManager to store their session data in the same database. This way webapp A deployed on machine A with context path "/a" could access the session data for the redundant/duplicate webapp B deployed on machine B with the same context path "/a" (assuming the 2 machines are in a cluster or behind a load balancer such that the hostname is the same for all requests). See the Chapter about Customizable Session Management in the SE 5.x User Guide for more information.
    • Prior to SE 5.0, a passive SE instance that has just been made active will have no knowledge of the session data that was maintained by the previously active instance. This is because by default, session data is only read in from disk by SE upon SE startup. So this solution does not allow the sharing of session data across multiple SE instances. You'd have to do "sticky" load balancing in that case.

company media information terms of use privacy policy contact us