Problem in enabling clustering on 2 nodes in JBoss 3.2.8SP1
by Abhinav Solan
Hi I have been trying to enable clustering on 2 ubuntu machines on JBoss
3.2.8SP1( I cant move to JBoss 4 as my application is configurable for
3.2.8SP1 only) but the 2 machines are not able to discover each other,
other machine is showing
11:23:10,526 INFO [DefaultPartition] Number of cluster members: 1
11:23:10,526 INFO [DefaultPartition] Other members: 0
both are having the same cluster-service file and have their IPV6,
disabled can some one please help me in this ...
Here is the log on my machine
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1
JAVA: /usr/lib/jvm/java-6-sun-1.6.0.06//bin/java
JAVA_OPTS: -server -Dprogram.name=run.sh
CLASSPATH: /home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/bin/run.jar:/usr/lib/jvm/java-6-sun-1.6.0.06//lib/tools.jar
=========================================================================
11:22:20,032 INFO [Server] Starting JBoss (MX MicroKernel)...
11:22:20,199 INFO [Server] Release ID: JBoss [WonderLand] 3.2.8.SP1
(build: CVSTag=JBoss_3_2_8_SP1 date=200603031235)
11:22:20,200 INFO [Server] Home
Dir: /home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1
11:22:20,200 INFO [Server] Home URL:
file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/
11:22:20,201 INFO [Server] Patch URL: null
11:22:20,202 INFO [Server] Server Name: all
11:22:20,202 INFO [Server] Server Home
Dir: /home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all
11:22:20,202 INFO [Server] Server Home URL:
file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/
11:22:20,202 INFO [Server] Server Temp
Dir: /home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/tmp
11:22:20,203 INFO [Server] Root Deployment Filename: jboss-service.xml
11:22:24,687 INFO [ServerInfo] Java version: 1.6.0_06,Sun Microsystems
Inc.
11:22:24,687 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM
10.0-b22,Sun Microsystems Inc.
11:22:24,687 INFO [ServerInfo] OS-System: Linux 2.6.24-19-generic,i386
11:22:28,063 INFO [Server] Core system initialized
11:22:45,167 INFO [Log4jService$URLWatchTimerTask] Configuring from URL:
resource:log4j.xml
11:22:51,550 INFO [WebService] Using RMI server codebase:
http://abhinav-desktop:8083/
11:22:55,210 INFO [NamingService] JNDI bootstrap JNP=/0.0.0.0:1099,
RMI=/0.0.0.0:1098, backlog=50, no client SocketFactory, Server
SocketFactory=class org.jboss.net.sockets.DefaultSocketFactory
11:23:06,249 INFO [SnmpAgentService] SNMP agent going active
11:23:06,486 INFO [RARMetaData] Required license terms present. See
deployment descriptor.
11:23:06,571 INFO [RARMetaData] Loading JBoss Resource Adapter for JDBC
2 XA drivers
11:23:06,571 INFO [RARMetaData] Required license terms present. See
deployment descriptor.
11:23:06,645 INFO [RARMetaData] Required license terms present. See
deployment descriptor.
11:23:08,344 INFO [DefaultPartition] Initializing
11:23:08,496 INFO [UDP] unicast sockets will use interface 127.0.1.1
11:23:08,503 INFO [UDP] socket information:
local_addr=abhinav-desktop:56543 (additional data: 14 bytes),
mcast_addr=228.1.2.3:45566, bind_addr=/127.0.1.1, ttl=8
sock: bound to 127.0.1.1:56543, receive buffer size=131071, send buffer
size=131071
mcast_recv_sock: bound to 127.0.1.1:45566, send buffer size=131071,
receive buffer size=131071
mcast_send_sock: bound to 127.0.1.1:54431, send buffer size=131071,
receive buffer size=131071
11:23:08,506 INFO [STDOUT]
-------------------------------------------------------
GMS: address is abhinav-desktop:56543 (additional data: 14 bytes)
-------------------------------------------------------
11:23:10,526 INFO [DefaultPartition] Number of cluster members: 1
11:23:10,526 INFO [DefaultPartition] Other members: 0
11:23:10,527 INFO [DefaultPartition] Fetching state (will wait for 60000
milliseconds):
11:23:10,528 INFO [DefaultPartition] New cluster view for partition
DefaultPartition (id: 0, delta: 0) : [127.0.1.1:1099]
11:23:10,626 INFO [DefaultPartition] I am (127.0.1.1:1099) received
membershipChanged event:
11:23:10,678 INFO [DefaultPartition] Dead members: 0 ([])
11:23:10,678 INFO [DefaultPartition] New Members : 0 ([])
11:23:10,678 INFO [DefaultPartition] All Members : 1 ([127.0.1.1:1099])
11:23:10,701 INFO [HANamingService] Listening on /0.0.0.0:1100
11:23:10,751 INFO [DetachedHANamingService$AutomaticDiscovery] Listening
on /0.0.0.0:1102, group=230.0.0.4, HA-JNDI address=127.0.1.1:1100
11:23:13,838 INFO [orb] ORB run
11:23:14,303 INFO [CorbaNamingService] Naming:
[IOR:000000000000002B49444C3A6F6D672E6F72672F436F734E616D696E672F4E616D696E67436F6E746578744578743A312E300000000000010000000000000064000102000000000A3132372E302E312E31000DC8000000114A426F73732F4E616D696E672F726F6F74000000000000020000000000000008000000004A414300000000010000001C00000000000100010000000105010001000101090000000105010001]
11:23:14,527 INFO [MailService] Mail Service bound to java:/Mail
11:23:14,982 INFO [TreeCache] setting cluster properties from xml to:
UDP(ip_mcast=true;ip_ttl=8;loopback=false;mcast_addr=230.1.2.3;mcast_port=45577;mcast_recv_buf_size=80000;mcast_send_buf_size=150000;ucast_recv_buf_size=80000;ucast_send_buf_size=150000):PING(down_thread=false;num_initial_members=3;timeout=2000;up_thread=false):MERGE2(max_interval=20000;min_interval=10000):FD_SOCK:VERIFY_SUSPECT(down_thread=false;timeout=1500;up_thread=false):pbcast.NAKACK(down_thread=false;gc_lag=50;max_xmit_size=8192;retransmit_timeout=600,1200,2400,4800;up_thread=false):UNICAST(down_thread=false;min_threshold=10;timeout=600,1200,2400;window_size=100):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):FRAG(down_thread=false;frag_size=8192;up_thread=false):pbcast.GMS(join_retry_timeout=2000;join_timeout=5000;print_local_addr=true;shun=true):pbcast.STATE_TRANSFER(down_thread=true;up_thread=true)
11:23:14,998 INFO [TreeCache] interceptor chain is:
class org.jboss.cache.interceptors.CallInterceptor
class org.jboss.cache.interceptors.LockInterceptor
class org.jboss.cache.interceptors.UnlockInterceptor
class org.jboss.cache.interceptors.ReplicationInterceptor
11:23:14,999 INFO [TreeCache] cache mode is REPL_ASYNC
11:23:15,055 INFO [UDP] unicast sockets will use interface 127.0.1.1
11:23:15,059 INFO [UDP] socket information:
local_addr=abhinav-desktop:43561, mcast_addr=230.1.2.3:45577,
bind_addr=/127.0.1.1, ttl=8
sock: bound to 127.0.1.1:43561, receive buffer size=80000, send buffer
size=131071
mcast_recv_sock: bound to 127.0.1.1:45577, send buffer size=131071,
receive buffer size=80000
mcast_send_sock: bound to 127.0.1.1:50021, send buffer size=131071,
receive buffer size=80000
11:23:15,060 INFO [STDOUT]
-------------------------------------------------------
GMS: address is abhinav-desktop:43561
-------------------------------------------------------
11:23:17,129 INFO [TreeCache] state could not be retrieved (must be
first member in group)
11:23:17,129 INFO [TreeCache] viewAccepted(): new members:
[abhinav-desktop:43561]
11:23:17,223 INFO [TreeCache] new cache is null (maybe first member in
cluster)
11:23:17,431 INFO [Embedded] Catalina naming disabled
11:23:17,960 INFO [Http11Protocol] Initializing Coyote HTTP/1.1 on
http-0.0.0.0-8080
11:23:18,001 INFO [Catalina] Initialization processed in 523 ms
11:23:18,028 INFO [StandardService] Starting service jboss.web
11:23:18,031 INFO [StandardEngine] Starting Servlet Engine: Apache
Tomcat/5.0.30
11:23:18,044 INFO [StandardHost] XML validation disabled
11:23:18,093 INFO [Catalina] Server startup in 66 ms
11:23:18,177 INFO [TomcatDeployer] deploy, ctxPath=/invoker,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy/http-invoker.sar/invoker.war/
11:23:19,204 INFO [TomcatDeployer] deploy, ctxPath=/jboss-net,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy/jboss-net.sar/jboss-net.war/
11:23:19,396 INFO [TomcatDeployer] deploy, ctxPath=/,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy/jbossweb-tomcat50.sar/ROOT.war/
11:23:19,608 INFO [TomcatDeployer] deploy, ctxPath=/jbossmq-httpil,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy-hasingleton/jms/jbossmq-httpil.sar/jbossmq-httpil.war/
11:23:19,801 INFO [DefaultDS] Bound connection factory for resource
adapter for ConnectionManager
'jboss.jca:service=LocalTxCM,name=DefaultDS to JNDI name
'java:/DefaultDS'
11:23:20,047 INFO [A] Bound to JNDI name: queue/A
11:23:20,048 INFO [B] Bound to JNDI name: queue/B
11:23:20,050 INFO [C] Bound to JNDI name: queue/C
11:23:20,051 INFO [D] Bound to JNDI name: queue/D
11:23:20,052 INFO [ex] Bound to JNDI name: queue/ex
11:23:20,078 INFO [testTopic] Bound to JNDI name: topic/testTopic
11:23:20,080 INFO [securedTopic] Bound to JNDI name: topic/securedTopic
11:23:20,082 INFO [testDurableTopic] Bound to JNDI name:
topic/testDurableTopic
11:23:20,085 INFO [testQueue] Bound to JNDI name: queue/testQueue
11:23:20,125 INFO [UILServerILService] JBossMQ UIL service available
at : /0.0.0.0:8093
11:23:20,215 INFO [DLQ] Bound to JNDI name: queue/DLQ
11:23:20,239 INFO [JmsXA] Bound connection factory for resource adapter
for ConnectionManager 'jboss.jca:service=TxCM,name=JmsXA to JNDI name
'java:/JmsXA'
11:23:20,331 INFO [TomcatDeployer] deploy, ctxPath=/jmx-console,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy/jmx-console.war/
11:23:20,535 INFO [TomcatDeployer] deploy, ctxPath=/web-console,
warUrl=file:/home/abhinav/Work/jboss_server/trial/jboss-3.2.8.SP1/server/all/deploy/management/web-console.war/
11:23:21,524 INFO [Http11Protocol] Starting Coyote HTTP/1.1 on
http-0.0.0.0-8080
11:23:21,779 INFO [ChannelSocket] JK2: ajp13 listening on /0.0.0.0:8009
11:23:21,909 INFO [JkMain] Jk running ID=0 time=0/153 config=null
11:23:21,931 INFO [Server] JBoss (MX MicroKernel) [3.2.8.SP1 (build:
CVSTag=JBoss_3_2_8_SP1 date=200603031235)] Started in 1m:1s:726ms
Here is my cluster-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
=====================================================================
-->
<!-- -->
<!-- Sample Clustering Service Configuration -->
<!-- -->
<!--
=====================================================================
-->
<!--
====================================================================
-->
<!-- Cluster Partition: defines cluster -->
<!--
====================================================================
-->
<!-- Name of the partition being built -->
${jboss.partition.name:DefaultPartition}
<!-- The address used to determine the node name -->
${jboss.bind.address}
<!-- Determine if deadlock detection is enabled -->
False
<!-- Time in milliseconds to wait for state to be transferred -->
60000
<!-- The JGroups protocol configuration -->
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address -->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="228.1.2.3" mcast_port="45566"
ip_ttl="8" ip_mcast="true"
mcast_send_buf_size="800000" mcast_recv_buf_size="150000"
ucast_send_buf_size="800000" ucast_recv_buf_size="150000"
loopback="false" />
<PING timeout="2000" num_initial_members="3"
up_thread="true" down_thread="true" />
<MERGE2 min_interval="10000" max_interval="20000" />
<FD shun="true" up_thread="true" down_thread="true"
timeout="2500" max_tries="5" />
<VERIFY_SUSPECT timeout="3000" num_msgs="3"
up_thread="true" down_thread="true" />
<pbcast.NAKACK gc_lag="50" retransmit_timeout="300,600,1200,2400,4800"
max_xmit_size="8192"
up_thread="true" down_thread="true" />
<UNICAST timeout="300,600,1200,2400,4800" window_size="100"
min_threshold="10"
down_thread="true" />
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="true" down_thread="true" />
<FRAG frag_size="8192"
down_thread="true" up_thread="true" />
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true" />
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true" />
<!--
====================================================================
-->
<!-- HA Session State Service for SFSB -->
<!--
====================================================================
-->
jboss:service=${jboss.partition.name:DefaultPartition}
<!-- Name of the partition to which the service is linked -->
${jboss.partition.name:DefaultPartition}
<!-- JNDI name under which the service is bound -->
/HASessionState/Default
<!-- Max delay before cleaning unreclaimed state.
Defaults to 30*60*1000 => 30 minutes -->
0
<!--
====================================================================
-->
<!-- HA JNDI -->
<!--
====================================================================
-->
jboss:service=${jboss.partition.name:DefaultPartition}
<!-- Name of the partition to which the service is linked -->
${jboss.partition.name:DefaultPartition}
<!-- bind address of HA JNDI RMI endpoint -->
${jboss.bind.address}
<!-- RmiPort to be used by the HA-JNDI service
once bound. 0 => auto. -->
1101
<!-- Port on which the HA-JNDI stub is made available -->
1100
<!-- Backlog to be used for client-server RMI
invocations during JNDI queries -->
50
<!-- Multicast Address and Group used for auto-discovery -->
${jboss.partition.udpGroup:230.0.0.4}
1102
<!-- IP Address to which should be bound: the Port, the RmiPort and
the AutoDiscovery multicast socket. -->
<!-- Client socket factory to be used for client-server
RMI invocations during JNDI queries -->
<!--attribute name="ClientSocketFactory">custom</attribute-->
<!-- Server socket factory to be used for client-server
RMI invocations during JNDI queries -->
<!--attribute name="ServerSocketFactory">custom</attribute-->
${jboss.bind.address}
4447
<!--
0
custom
custom
-->
<!--
====================================================================
-->
<!-- Distributed cache invalidation -->
<!--
====================================================================
-->
jboss:service=${jboss.partition.name:DefaultPartition}
jboss.cache:service=InvalidationManager
jboss.cache:service=InvalidationManager
${jboss.partition.name:DefaultPartition}
DefaultJGBridge
Here is my tc5-cluster-service.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
=====================================================================
-->
<!-- -->
<!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering
-->
<!-- -->
<!--
=====================================================================
-->
<!--
====================================================================
-->
<!-- Defines TreeCache configuration -->
<!--
====================================================================
-->
jboss:service=Naming
jboss:service=TransactionManager
<!-- Configure the TransactionManager -->
org.jboss.cache.JBossTransactionManagerLookup
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ
<!--
Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
-->
REPL_ASYNC
<!-- Name of cluster. Needs to be the same for all clusters, in order
to find each other
-->
Tomcat-Cluster
<!-- JGroups protocol stack properties. Can also be a URL,
e.g. file:/home/bela/default.xml
-->
<!-- UDP: if you have a multihomed machine,
set the bind_addr attribute to the appropriate NIC IP address, e.g
bind_addr="192.168.0.2"
-->
<!-- UDP: On Windows machines, because of the media sense feature
being broken with multicast (even after disabling media sense)
set the loopback attribute to true -->
<UDP mcast_addr="230.1.2.3" mcast_port="45577"
ip_ttl="8" ip_mcast="true"
mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
loopback="false"/>
<PING timeout="2000" num_initial_members="3"
up_thread="false" down_thread="false"/>
<MERGE2 min_interval="10000" max_interval="20000"/>
<FD_SOCK/>
<VERIFY_SUSPECT timeout="1500"
up_thread="false" down_thread="false"/>
<pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
max_xmit_size="8192" up_thread="false" down_thread="false"/>
<UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
down_thread="false"/>
<pbcast.STABLE desired_avg_gossip="20000"
up_thread="false" down_thread="false"/>
<FRAG frag_size="8192"
down_thread="false" up_thread="false"/>
<pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
shun="true" print_local_addr="true"/>
<pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
<!-- Max number of milliseconds to wait for a lock acquisition -->
15000
17 years, 8 months
[Design of JBoss Remoting, Unified Invokers] - Re: Remoting unmarshalling vs. class loaders
by scott.stark＠jboss.org
"david.lloyd(a)jboss.com" wrote : So as long as you keep your requests confined to a single classloader (on the receiving side) then things should work out. I think that associating a service with its appropriate classloader would be the right thing to do there (the protocol handler would then choose the classloader based on the service being invoked). Given the R3 design, which makes requests and client instances much more lightweight, mixing classloaders in requests would be an indication of improper service design - if you're doing that, you probably need multiple services (one for each aspect that lives in its own classloader).
|
Agreed, the target of the remoting invocation should have a distinct class loader that would be set as the request TCL. However, if there is a lazy or streaming facility that allows the marshalling to occur at the remoting layer and there is object replacement via replaceObject, proxy replacement, etc., the marshaller needs the handler TCL saved for the duration of the response. Is there a way the handler can associate that with the response object?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169179#4169179
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169179
17 years, 8 months
[Design of JBoss Remoting, Unified Invokers] - Remoting unmarshalling vs. class loaders
by david.lloyd＠jboss.com
"scott.stark(a)jboss.org" wrote : I have been talking to Ron about some current remoting class loading issues that arise from the invocation handler being the only one who knows the correct class loader for unmarshalling application specific classes:
|
| 1. thread pool receives a remoting request.
| 2. unmarshall just enough to understand the request, but don't unmarshall any invocation payload. Application specific data needs to be isolated outside of the remoting control structures to allow this to happen.
| 3. dispatch the request to a handler.
| 4. handler sets the TCL
| 5. handler or its delegate unmarshalls application payload
| 6. application does what is does.
| 7. handler serializes application return/exception and then unsets the TCL
| 8. remoting layer completes request control information
|
So the core of this issue is that Remoting 2 mixes control objects in with the invocation payload in the wire protocol. Or put more generally, a request may be comprised of objects that have to be unmarshalled by different classloaders, where the proper classloader may not be evident based on the current unmarshalling state. (Let me know if I'm not understanding something...)
In R3 this is solved in part because there's no Remoting control data in the request itself. So as long as you keep your requests confined to a single classloader (on the receiving side) then things should work out. I think that associating a service with its appropriate classloader would be the right thing to do there (the protocol handler would then choose the classloader based on the service being invoked). Given the R3 design, which makes requests and client instances much more lightweight, mixing classloaders in requests would be an indication of improper service design - if you're doing that, you probably need multiple services (one for each aspect that lives in its own classloader).
(Deliberately not yet broaching the topic of R3's remote classloading system)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169178#4169178
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169178
17 years, 8 months
[Design of JBossCache] - Re: Common marshalling infrastructure
by david.lloyd＠jboss.com
"scott.stark(a)jboss.org" wrote : So where does the invocation target class loader fit in, I don't see it in the apis.
It's factored out of the API currently - you'd have a customized ClassUnmarshaller that looks up the class in the appropriate classloader, similarly to how standard serialization works. The reason is that I can't really think of a good general solution (the needs of JBC & JBREM are very different in this area for example).
"scott.stark(a)jboss.org" wrote : I have been talking to Ron about some current remoting class loading issues that arise from the invocation handler being the only one who knows the correct class loader for unmarshalling application specific classes:
|
| 1. thread pool receives a remoting request.
| 2. unmarshall just enough to understand the request, but don't unmarshall any invocation payload. Application specific data needs to be isolated outside of the remoting control structures to allow this to happen.
| 3. dispatch the request to a handler.
| 4. handler sets the TCL
| 5. handler or its delegate unmarshalls application payload
| 6. application does what is does.
| 7. handler serializes application return/exception and then unsets the TCL
| 8. remoting layer completes request control information
|
This particular problem is specific to Remoting, so if you don't mind I'm going to move this bit back over to those forums before I reply...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169176#4169176
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169176
17 years, 8 months
[Design of JBossCache] - Re: Common marshalling infrastructure
by scott.stark＠jboss.org
So where does the invocation target class loader fit in, I don't see it in the apis.
I have been talking to Ron about some current remoting class loading issues that arise from the invocation handler being the only one who knows the correct class loader for unmarshalling application specific classes:
1. thread pool receives a remoting request.
2. unmarshall just enough to understand the request, but don't unmarshall any invocation payload. Application specific data needs to be isolated outside of the remoting control structures to allow this to happen.
3. dispatch the request to a handler.
4. handler sets the TCL
5. handler or its delegate unmarshalls application payload
6. application does what is does.
7. handler serializes application return/exception and then unsets the TCL
8. remoting layer completes request control information
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4169175#4169175
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4169175
17 years, 8 months