4 Replies Latest reply on Feb 23, 2007 10:07 AM by Brian Stansberry

    Pooling in Buddy Replication

    Vishal K Newbie

      Hi Friends,

      This is regarding buddy pooling
      I have the folowing element

      <buddyPoolName>default</buddyPoolName>


      for the buddy replication

      What is its Significance?

      Because I have a set of four nodes node1,node2,node3,node4

      node1 and node2 have
      <buddyPoolName>pool1</buddyPoolName>

      node3 and node3 have
      <buddyPoolName>pool2</buddyPoolName>


      according to me if node1 and node2 fail - application should fail since I was running the app say from "pool1",

      and nodes from the other pool will not contain session data backed up for nodes from pool1..


      Am I right??

      Your thoughts are appreciated in advance.

      Waiting for your responses.

      Thanks
      Vishal

        • 1. Re: Pooling in Buddy Replication
          Manik Surtani Master

           



          according to me if node1 and node2 fail - application should fail since I was running the app say from "pool1",

          and nodes from the other pool will not contain session data backed up for nodes from pool1..



          Correct.

          The purpose of buddy pools are described in the user guide.

          • 2. Re: Pooling in Buddy Replication
            Vishal K Newbie

            Thanks Manik for your response!
            But I could not find this happening in my case.

            Let me explain
            Now my scenario is that - I have four nodes on my machine (four multiple instances on my machine)
            node1 and node2 --> pool1
            node3 and node4 --> pool2
            C:\jboss-4.0.5.GA\server\node4\deploy\tc5-cluster.sar\META-INF\jboss-service.xml -- This is the file which I changed


            I deployed the application war on all the nodes.

            I have Apache+mod_jk configured for my jboss. I am calling my application now in the browser.

            http://localhost/OnlineShopping - I click on submit to log in

            It gives me a URL like this

            http://localhost/OnlineShopping/login.do;jsessionid=wdlhqzxNG1lDE56xWLSzaA**.node2

            And I assume that my request was served by node2

            Now I stop node2 after doing some shopping and there is data in the session
            APP is working fine here.

            Now I stop node1
            APP is working fine -- But Application has not failed because node1 and node2 were from pool1.

            It seems here that application has data backed up on node3 and node4 (which are from pool2)

            because when I stop now node3

            My Application is still running fine. I can continue shopping and data is successfully retrievable from session and so on

            It does not FAIL.

            Now I don't understand why it does not fail?
            What is the meaning of pool-names here by naming pool1 for node1 and node2
            and pool2 for node3 and node4.

            Can you please explain/suggest more?

            Thanks
            Vishal

            • 3. Re: Pooling in Buddy Replication
              Manik Surtani Master

               


              It seems here that application has data backed up on node3 and node4 (which are from pool2)


              What makes you think this is the case? A good way to tell is to use the JMX console on each node and dump cache contents to see where the data is and where the backups are.

              In your scenario, you have:

              Pool1: node1, node2
              Pool2: node3, node4

              When you use the app (assume you start on node2 as your example suggests) your state is backed up on node1 since it is in the same pool.

              When you kill node2, your app continues to work since the state is available on node1.

              Now node1 NEEDS a new backup node. Since there are no other nodes in pool1, it is forced to pick a node from elsewhere (such as in pool2).

              Basically, these pools are only _hints_ on how to select a backup node. The algorithm is:

              1) Try and select buddy from same pool, on different host.
              2) Else, try and select buddy from same pool, on same host.
              3) Else, try and select buddy from different pool, on different host.
              4) Else, try and select buddy from different pool, on same host.
              5) Finally fall back to no buddy.

              See NextMemberBuddyLocator.locateBuddies() for details of how this is implemented.


              • 4. Re: Pooling in Buddy Replication
                Brian Stansberry Master

                A key thing to understand is that if you'd killed *both* node1 and node2 at the same time, the data would have been lost. This would be the case even if all 4 nodes had the same buddy pool, but node2 had happened to pick node1.

                Even if node1 and node2 were not killed at the same time, but node1 was killed before you'd accessed the session again somewhere, the data would have been lost. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=99251 for a discussion of why that is.

                A third scenario:

                1) Start on node2. The buddy is node1 since they have the same pool name.
                2) Kill node1.
                3) Kill node2.
                4) Make another request. Should work. This is because when you killed node1, node2 detected that and chose another buddy. So your session would have been backed up on node3 or 4, and would still be available.