7 Replies Latest reply: Nov 15, 2010 4:25 PM by 161734 RSS

    Weblogic Timer Event Generator - How it works?

    803431
      Hello everyone!

      I have wrote simple wli-application, that subscribes to the message broker channel.

      I have deployed it to the cluster (managed servers 1 (ms1) and 2(ms2)). (I use Weblogic Server 10.3, cluster contains 1 admin server and 2 managed servers.)

      Than I have created the timer event generator (EG) via wliconsole and rule for this EG - to send message to the MB-channel every 30 seconds.

      Then I redeploy EG application via console (WLS Admin Console) from managed server 1 to cluster (m.servers 1 and 2) and start it.

      Everything started ok - I got messages to both instatnces of my application in the following way:
      15:30:00 - to instance on ms1
      15:30:30 - to instance on ms2
      15:31:00 - to instance on ms1
      15:31:30 - to instance on ms2
      ...and so on

      when I shut down ms2 - I started to receive messages to instance of my application on ms1 every 30 secodns. Here Everything is OK.

      Then I start ms 2 and got the picture like:
      15:30:00 - to instance on ms1
      15:30:30 - to instance on ms2
      15:31:00 - to instance on ms1
      15:31:30 - to instance on ms2
      ...and so on

      Then I shutdown ms1... And that's all - no messages to instance on ms2 :(

      I started ms1 and no messages on both instances - on ms1 and ms2..

      Can you explain me how Timer Event Generator works? What resources it uses? And how can I setup it to get load-balancing while both instances running and failover - when one of the instances shutdowned?

      Thanks in advance,
      Vladimir.
        • 1. Re: Weblogic Timer Event Generator - How it works?
          746124
          Hi Vladimir,

          According to http://download.oracle.com/docs/cd/E14981-01/wli/docs1031/deploy/cluster.html#wp1519038, the timer EG + "will be active on the managed server containing the migratable server with the queues associated with the specific event generator (for example, wli.internal.egmail.queue for an email event generator)"+

          Is the queue for your EG migratable ? it seems to me that the queue does not migrate from ms1 back to ms2 when you turn the latter on.
          • 2. Re: Weblogic Timer Event Generator - How it works?
            803431
            Hi! Thank you for the answer.

            I solved this problem recently. Solution included the following steps:
            1. Set migration to consensus (i didn't want to create aditional tables etc and choose this migration basis).
            2. Create migratable target with the Service Migration Policy: «Auto-Migrate Exactly-Once Services».
            3. Create persistent store targeted to migratable target.
            4. Create jms server based on this persistent store.
            5. Redeploy wli.internal.egtimer.queue to the created jms-server.
            6. For the weblogic.jws.jms.QueueConnectionFactory in the config file I set Load Balance to true and Server Affinity Enabled to false. This allows in future not only failover feature but the "load balancing" too.
            7. Message broker queue of my application (APPXXX..queue.AsyncDispatcher) I create like uniform distributed or simple distributed queue and deploy it to whole cluster.

            The actions above allows to work timer event generator in the way I need:
            - Fired events runs subscribed application on both nodes with the load balancing
            - And in the case of failure of one of nodes the migratable target goes to the working node and everything continues working :) - failover here!

            But when deployed on cluster timer event generator must be started and stopped not via wliconsole, but via deployments in web admin console of weblogic server.
            • 3. Re: Weblogic Timer Event Generator - How it works?
              161734
              I'm trying to achieve the same result but i get errors on AdminServer when i create the Migratable Target.

              java.lang.IllegalArgumentException: Cannot add Singleton Service <MigratableTarget> as SingletonServicesManager not started. Check if MigrationBasis for cluster is configured.

              MigrationBasis is configured as Consensus.

              Did you get those as well? Can you help me to resolve this? So i have to start the AdminServer through the NodeManager?

              Thanks in advance
              • 4. Re: Weblogic Timer Event Generator - How it works?
                803431
                Hi!
                :) my cluster has the following settings:
                1. Messaging: Multicast
                2. Multicast address: 239.192.0.0
                3. Multicast port: the same as admin server has
                4. Yes, I have nodemanager running and both managed servers running.. Here I think that at least one managed server must be running while creating and starting managed target. Or there is no place to host this target :)
                5. Migration basis Consensus and in "Candidate Machines For Migratable Servers:" I choose the machine that controls my managed servers (it (machine) was created when I created the cluster).. And you must move to choosen window of "Candidate Machines For Migratable Servers:" the machines of all managed servers on which you want to host migratable target.

                :) well.. Ask me if these comments will not help you. And next time give me more detailed description of your cluster :)
                • 5. Re: Weblogic Timer Event Generator - How it works?
                  161734
                  Hi Vladimir, first of all i would like to thank you for good will and the quick reply, i really appretiate it =)

                  I feel like i'm missing something, but honestly i can't figure out what it is... And it's driving me nuts =)

                  I have that same "vanilla" configuration, Production Mode, one AdminServer, 2 Managed Servers on the same machine, all with static IP and different ports configured.
                  The Multicast address is exactly the same as yours, as well as the port.
                  I don't know if this could be relevant but i've used the PointBase default configuration for the Data Sources.
                  I've configured the cluster address using the IP i've assigned to the servers. Configured the FrontEndHost and FrontEndPort with that same values as the AdminServer.
                  Relocated the Persistent Stores and JMS Servers, since some were incorrectly pointing to the AdminServer. Created the JSP_<PROCESS> table in the database.

                  I get the job running being load balanced between the Managed Servers, and if i kill server B (the one where the Timer Event Generator queue is NOT deployed) the server A picks up the events and processes them. If i kill server A, well, you know what happens ;)

                  Happy days and all goes well... Until i decide to create a Migratable Target, once i do that if i restart the AdminServer hell breaks loose and i have some nasty exceptions on the console.

                  I don't know you had the same problem...

                  If you can forgive me, i would like to ask you a couple more questions (once again thanks a lot)...

                  Regarding "5. Redeploy wli.internal.egtimer.queue to the created jms-server.", do you mean editing %DOMAIN_HOME%\config\jms\configwiz-jms.xml, removing the queue wli.internal.egtimer.queue and creating it under a different subdeployment on the created jms server?
                  • 6. Re: Weblogic Timer Event Generator - How it works?
                    803431
                    Hi there! :)
                    Well.. I had not such a problem.. I had some exceptions in my admin server log when I started it while managed servers were in shutdown. In that case migratable target had no places to host on.
                    So you wrote that:

                    - I've configured the cluster address using the IP i've assigned to the servers.
                    -- it means that it is like: 192.168.70.120:8013,192.168.70.120:8113 - ip's & PORT, yes?

                    - Configured the FrontEndHost and FrontEndPort with that same values as the AdminServer.
                    -- and you have the http-proxy deployed on your admin server? 'cause front-end host and port - must be the host and port of http-proxy that performs load-balancing for requests to your processes on your managed servers.

                    - Relocated the Persistent Stores and JMS Servers since some were incorrectly pointing to the AdminServer.
                    I didn't understand about what p.stores you are talking about.. I meant that you must create new JDBC p.store with table in cgDataSource and targeted to migratable target. And than you must create a new jms-server, which hosted to this p.store.
                    ...But I didn't retarget any existing p.stores......

                    - Created the JSP_<PROCESS> table in the database.
                    -- and what is this? :)

                    - Regarding "5. Redeploy wli.internal.egtimer.queue to the created jms-server.", do you mean editing %DOMAIN_HOME%\config\jms\configwiz-jms.xml, removing the queue wli.internal.egtimer.queue and creating it under a different subdeployment on the created jms server?
                    -- yes. And the same story with the connection factory with the JNDI-name: weblogic.jws.jms.QueueConnectionFactory, which resides in the conversational-jms module under the name cgQueue. It's settings in the configuration file must be something like this:

                    <connection-factory name="cgQueue">
                    <sub-deployment-name>cgQueue</sub-deployment-name>
                    <jndi-name>weblogic.jws.jms.QueueConnectionFactory</jndi-name>
                    <client-params>
                    <acknowledge-policy>All</acknowledge-policy>
                    <allow-close-in-onMessage>true</allow-close-in-onMessage>
                    <messages-maximum>1</messages-maximum>
                    <multicast-overrun-policy>KeepOld</multicast-overrun-policy>
                    <synchronous-prefetch-mode>disabled</synchronous-prefetch-mode>
                    <reconnect-policy>all</reconnect-policy>
                    <reconnect-blocking-millis>60000</reconnect-blocking-millis>
                    <total-reconnect-period-millis>-1</total-reconnect-period-millis>
                    </client-params>
                    <load-balancing-params>
                         <server-affinity-enabled>false</server-affinity-enabled>
                    </load-balancing-params>
                    <transaction-params>
                    <xa-connection-factory-enabled>true</xa-connection-factory-enabled>
                    </transaction-params>
                    </connection-factory>

                    pay your attention on lines:
                    <acknowledge-policy>All</acknowledge-policy>
                    <server-affinity-enabled>false</server-affinity-enabled>

                    ..and, of course, you must use this connection factory in your timer event generators while creating it :)

                    well.. And one more question - may be you speak russian? ))))))))) simply I had described the whole process in document, but it is in russian..
                    • 7. Re: Weblogic Timer Event Generator - How it works?
                      161734
                      Hi Vladimir, it seems like we must have different environments. I don't know if you used the latest version of wli or not...

                      So, not exactly for you, but for someone who happens to read this post, and has the same problems we did...

                      -- I've configured the cluster address using the IP i've assigned to the servers.
                      --- it means that it is like: 192.168.70.120:8013,192.168.70.120:8113 - ip's & PORT, yes?
                      Yes, that's the format we are using (http://download.oracle.com/docs/cd/E13222_01/wls/docs92/cluster/setup.html#wp751583)

                      -- Configured the FrontEndHost and FrontEndPort with that same values as the AdminServer.
                      --- and you have the http-proxy deployed on your admin server? 'cause front-end host and port - must be the host and port of http-proxy that performs load-balancing for requests to your processes on your managed servers.
                      Actually we don't need the HTTP load balance, we only start the process via EG events, so we only benifit from load balancing on the JMS queues, but i had to configure this to be able to start the process. We had errors if we didn't configure this. We used the AdminServer address and port.

                      -- Relocated the Persistent Stores and JMS Servers since some were incorrectly pointing to the AdminServer.
                      ---I didn't understand about what p.stores you are talking about.. I meant that you must create new JDBC p.store with table in cgDataSource and targeted to migratable target. And than you must create a new jms-server, which hosted to this p.store.
                      ...But I didn't retarget any existing p.stores......
                      Once the domain was created (didn't do anything but to follow the wizard) we had the persistent stores (and underlying JMS servers) targeted to the AdminServer (obviously incorrect). So we retargeted them to the Managed Server.

                      -- Created the JSP_<PROCESS> table in the database.
                      --- and what is this? :)
                      We had to create a table to persist the wli process state, because it is a statefull process (http://download.oracle.com/docs/cd/E13214_01/wli/docs102/dbtuning/wliTuning.html)

                      The matter of fact is everything works fine, despite the exceptions i mentioned in the AdminServer, once it gets started... But it seems to have no negative impact on the application, and migration is done successfully

                      I will continue to work on figuring out what the origin of those exceptions is, and if i manage to find a solution i, most surely, will post it here... One thing i find to be strange is that the exceptions start even before i have anything deployed to the Migratable Target... Once i create it and restart the server i get those messages, and we tried the Concensus configuration with NodeManager, as well as the Database configuration.

                      I guess that what's really important for us now is that we do have fail over and load balancing working... :D

                      I don't know if it would be abusive to ask you for that document of yours, maybe it has some clue on what's wrong in our config, but again, i understand if you can't share that =)
                      By the way, i'm portuguese, but since google made the translator available, i guess i can manage russian documentation as well ;)

                      I can't tell you how gratefull i am for your help, and for sharing your previous experience with the rest of us. If it wasn't for your altruism i guess i would be stuck with this for much longer... you sure saved my day... BIG BIG thank you..

                      Once again, thank you and i wish you all the best !!! I just wished i could be helpfull to you sometime =)