-
1. Re: Pooling in Buddy Replication
manik Feb 21, 2007 11:18 AM (in response to 2)
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
2 Feb 23, 2007 3:46 AM (in response to 2)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 Feb 23, 2007 7:49 AM (in response to 2)
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 Feb 23, 2007 10:07 AM (in response to 2)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.