Package replication for fail-over configuration

We have an environment where IS on two different servers are configured for failover.

We have two boxes, both of which have IS installed. At any time, only one of the boxes has IS running. If one of them is down, the clustering software brings the other server up along with the IS. We are not using the webMethods supplied clustering solution

This kind of configuration is causing two issues:

  1. Replication of packages across two IS. When a package needs to be migrated to production, it is imported into the IS which is running at that time and copied into the inbound replication area of the IS that is not running. When a fail-over situation occurs, someone needs to manually import the packages from the inbuond replication area. This requires human intervention and has been error prone.

Is there a simple way to import packages automatically at startup, as in several app servers? I have devised a round about way of accomplishing this (a java service lists the zip files present in the inbound area. A flow service gets the list imports them one by one. This flow service can be called at server startup. If there is an easier option, I can try that)
2. If there are active JDBC polling notifications at the time of active IS shutdown, this causes issues in enabling them on the failed-over IS. Is there a facility of having a service to be executed at server shutdown? If there is, I can create a flow service that disables the JDBC polling notifications gracefully

Instead of importing the package, just copy the package folder (in the /package directory) from the active IS box to the other. Then the package will load when the IS starts.

As for running a service at server shutdown, you can run a service when a package unloads, but I’m not sure any shutdown services will run if your IS crashes. Do you want the JDBC polling notifications to always be disabled on your inactive IS? It doesn’t seem that you would care the state of the JDBC polling notifications on an inactive IS. If the IS is inacive, the JDBC polling notifications will be inactive. On the other hand, you want to make sure that your JDBC polling notifications are active when the IS starts. You could writes a startup service that checks the status of your JDBC polling notifications and starts them if they are disabled.