-
1. Re: Clustering and Non-multicast JavaGroups config
belaban Oct 9, 2003 9:18 PM (in response to ckmod)In initial_hosts, you need to have *both* hosts listed
Bela -
2. Re: Clustering and Non-multicast JavaGroups config
ckmod Oct 10, 2003 6:06 AM (in response to ckmod)Hi Bela,
this does not work either. The servers still do not see each other. -
3. Re: Clustering and Non-multicast JavaGroups config
belaban Oct 10, 2003 6:59 AM (in response to ckmod)Show your prot spec here. Also, does the member address show 'localhost' ?
Bela -
4. Re: Clustering and Non-multicast JavaGroups config
ckmod Oct 21, 2003 4:39 AM (in response to ckmod)I am sorry for the delay but other things kept me busy...
I am not sure what you mean. In the meanwhile I have two servers working on the same machine.
Protocol Stack 1
<TCP start_port="7900" />
<TCPPING initial_hosts="FSDEHAMWS007[7800]"
port_range="5"
timeout="3000"
num_initial_members="2"
up_thread="true"
down_thread="true" />
<VERIFY_SUSPECT timeout="1500"
up_thread="false"
down_thread="false" />
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false"
down_thread="false" />
<pbcast.NAKACK gc_lag="100"
retransmit_timeout="3000"
up_thread="true"
down_thread="true" />
<pbcast.GMS join_timeout="5000"
join_retry_timeout="2000"
shun="false"
print_local_addr="false"
up_thread="true"
down_thread="true" />
Protocol Stack 2
<TCP start_port="7800" />
<TCPPING initial_hosts="FSDEHAMWS007[7900]"
port_range="5"
timeout="3000"
num_initial_members="2"
up_thread="true"
down_thread="true" />
<VERIFY_SUSPECT timeout="1500"
up_thread="false"
down_thread="false" />
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false"
down_thread="false" />
<pbcast.NAKACK gc_lag="100"
retransmit_timeout="3000"
up_thread="true"
down_thread="true" />
<pbcast.GMS join_timeout="5000"
join_retry_timeout="2000"
shun="false"
print_local_addr="false"
up_thread="true"
down_thread="true" />
The server see each other, failover is working.
BUT: The calls from the client application do not load balance
Here is the clients jndi.properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
java.naming.provider.url=10.0.144.77:1100,10.0.144.77:1200
java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
jnp.timeout=3000
jnp.sotimeout=3000 -
5. Re: Clustering and Non-multicast JavaGroups config
ckmod Oct 21, 2003 4:43 AM (in response to ckmod)Here are my cluster logfiles of both servers.
-
6. Re: Clustering and Non-multicast JavaGroups config
belaban Oct 21, 2003 9:11 AM (in response to ckmod)Regarding client calls not load balancing: you said client calls do failover (when server1 crashes, they get redirected to server2 right). Load balancing uses afaik a sticky LB policy, calls go to server1 as long as server1 is up. You can change the LB policy to use for example random robin, or round robin.
Bela -
7. Re: Clustering and Non-multicast JavaGroups config
ckmod Oct 21, 2003 10:59 AM (in response to ckmod)The failover might be a result of the client knowing both servers in his jndi.properties (?).
I have specified the load balancing in jboss.xml
<ejb-name>MyService</ejb-name>
<jndi-name>ejb/MyService</jndi-name>
<local-jndi-name>MyServiceLocal</local-jndi-name>
true
<cluster-config>
<partition-name>MyServicePartition</partition-name>
<home-load-balance-policy>org.jboss.ha.framework.interfaces.RoundRobin</home-load-balance-policy>
<bean-load-balance-policy>org.jboss.ha.framework.interfaces.RoundRobin</bean-load-balance-policy>
</cluster-config>
I will use different names for the different partitions: DevPartition, TestPartition and ProdPartition. This should avoid that servers from development, test and production env accidentally see each other.
But it is still weird why we can't bring this protocol stack to work as we want to...
Thank you very much for your help, Bela !