JMS failover

Question

          We have an external EDI service posting XML data over http to Weblogic JMS server,
          we have 2 physical machines which run the weblogic and JMS, our EDI can only feed
          to one server so if that server goes down what would be the best way to automactically
          failover to the other Weblogic JMS, since JMS server cannot be clustered.We are
          infact using a database based queue.
          Thanks
          Anil Jacob
          

Answer 1

          Hi Anil,
          you are correct that automatic migration is not supported in weblogic server so
          you will need to take care of this yourself.
          We have written a little java program that runs of the same server that our admin
          server is running on. This program has two purposes, one is to restart the admin
          server incase it should goes down. This is because the we need to trigger the
          migration through the admin server. The second is to poll the managed servers
          and and migrate when needed.
          The methods that handle the migration are located in weblogic.management.runtime.MigratableServiceCoordinatorRuntimeMBean.
          So as an example you could get a referense to this mbean by writing:
          MBeanHome home = Helper.getMBeanHome(wls_user, wls_password, admin_url, admin_server_name);
          MigratableServiceCoordinatorRuntime mrt = home.getRuntimeMBean("the-MigratableServiceCoordinator",
          "MigratableServiceCoordinatorRuntime");
          mrt.migrate(migratableTargetMBean, destinationServer, false, true);
          We are using bea`s types interfaces for this but you can also use "pure" jmx calls,
          but I was is a hurry and this seemed to be quicker.
          Below is the javadoc for the migrate method that bea`s support provided us.
          * Migrate all services deployed to the migratableTarget to the destination
          * server. Use this method if either the source or the destation or both are
          * not running.
          * Precondition:
          * The migratableTarget must contain at least one server.
          * The destination server must be a member of the migratableTarget's list
          of
          * candidate servers.
          * If automatic migration mode is disabled, the destination server must not
          * be the currently hosting server (i.e. head of candidate list of the
          * migratableTarget).
          * Postcondition:
          * If automatic migration mode is disabled and if the migration succeeded,
          * the head of the candidate server list in the migratableTarget will be the
          * destination server.
          * @param migratableTarget - all services targeted to this target are to be
          * migrated to the destination server.
          * THIS MUST BE A CONFIG MBEAN
          * @param destination - the new server where the services deployed to
          * migratableTarget shall be activated
          * @param sourceUp - the currently active server is up and running. If false,
          * the administrator must ensure that the services deployed
          * to migratableTarget are NOT active.
          * @param destinationUp - the destination server is up and running.
          void migrate(MigratableTargetMBean migratableTarget, ServerMBean destination,
          boolean sourceUp, boolean destinationUp) throws MigrationException;
          If you take a look at the weblogic.management.configuration.MigratableTargetMBean
          it has a method named getHostingServer(). This method returns a ServerMBean which
          tells us on which server the jms services are bound. This the same as the "CurrentServer"
          in the admin console. These objects have names like "appserver1 (migratable)"(where
          appserver1 would be replaced with the name of your managed server). This can
          be abit confusing if you look at the admin server log would can somtime see that
          is is migrating "appserver1 (migratable) to appserver1", which migth look stange(well
          it did for me:)). Just remember that "appserver1 (migratable)" is just the name
          of the migratable target, and that object has the "CurrentServer" attribute .
          The "CurrentServer" is the server where the services are right now, and it is
          that server that we are migrating the services from.
          I think that your ide of have inte a backup jms server running of a second wls
          will work just fine. You should be able to poll the server which is hosting the
          jms service, and if it goes down you migrate the migratable target to the second
          server. You could stop there and manually "reset" the configuration to your
          starting state or fully automate so that the second server takes over and the
          first becomes you back up.
          Just ask if some of this isn`t very clear.
          /Daniel
          "Anil Jacob" <[email protected]> wrote:
          >
          >Daniel,
          >
          >That was a pretty good explanation. Thanks. Our application vendor does
          >not support
          >distributed queues therefore right now that option might not be used
          >in our case,
          >however the migratable option for JMS that you discribed looks good.
          >Is migration
          >an automactic process, I don't think so, what do you say?
          >What I want to acheive given the limited options is to have a backup
          >Weblogic
          >JMS which would come alive once the primary goes down, in this case your
          >idea
          >of a script looks good, can you give me more details on the script that
          >polls
          >the managed server and migrates JMS incase of a failure?
          >
          >Thankx
          >Anil
          >
          >[email protected] (Daniel Bevenius) wrote:
          >>Hi,
          >>
          >>What you could do is have a distributed destination as the previous
          >>post suggested. This distributed destination could then have one
          >>member that is pinned to a JMS server on one of you`re managed
          >>servers. This JMSServer should have its target set to appserver1
          >>(migratable).
          >>
          >>
          >>In you`re case you say that you can only target one server with the
          >>EDI feed which means that you will need to manually migrate the jms
          >>services to the second server.
          >>
          >>We had to create a program that polls the servers to see if they are
          >>alive. If one goes down we migrate the jms services automatically to
          >>the server that is still up.
          >>
          >>You stated that JMS servers could not be clustered. In our setup we
          >>have a JMSServer on each managedserver(we have two in a cluster).
          >>According to BEA support the problem with automatic failover is with
          >>consumers that bind to a distributed destination(note that this is not
          >>so for producers).
          >>When a client binds to a distributed destination it will get a binding
          >>to one of the members of that distributed destinaion, which depends
          >on
          >>the load balancing policy(we use round robin). Lets say that the
          >>client binds to a jms server on our first managedserver. If this
          >>server crashes the the client will still have a binding to the first
          >>managed server. What we are migrating is the binding to a different
          >>jms server.
          >>
          >>Don`t know if this helps you at all but let me know and I`ll try to
          >>explain it better.
          >>
          >>/Daniel
          >>
          >>
          >>
          >>
          >>"Anil Jacob" <[email protected]> wrote in message news:<[email protected]>...
          >>> We have an external EDI service posting XML data over http to Weblogic
          >>JMS server,
          >>> we have 2 physical machines which run the weblogic and JMS, our EDI
          >>can only feed
          >>> to one server so if that server goes down what would be the best way
          >>to automactically
          >>> failover to the other Weblogic JMS, since JMS server cannot be clustered.We
          >>are
          >>> infact using a database based queue.
          >>>
          >>> Thanks
          >>> Anil Jacob
          >