[Installation, Configuration & DEPLOYMENT] - Re: ServiceBindingManager in Jboss5
by PeterJ
First, did you change the binding.xml file other that the one line you listed?
Second, if you do not bring up the first JBoss AS instance, and only bring up the second, do you still get the same error? If so, something else is using that port, or preventing you from opening that port (firewall?)
Third, you don't need to change the bindings.xml file at all, you can choose which binding config to use like this:
./run/sh -c xxx -D-Djboss.service.binding.set=ports-01
If you don't want to type this all the time, create another script containing the above line (that's what I usually do if I need to run multiple instances)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204382#4204382
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204382
17 years, 3 months
[JBoss Cache: Core Edition] - Replicated Cache - Failover & Failback
by abcdefg1234
We have a 2 node replicated cache i.e.
node1 --> application instance 1 --> cache instance 1
node2 --> application instance 2 --> cache instance 2
According to the configuration below, everything seems to work fine. i.e when node 1 is shutdown and brought back up, any changes made to cache instance 2 are replicated.
Problem: - However, what if the application server node is still running, but only the cache instance on node 1 has to be shutdown or crashes. I would think that the application on node 1 can access to the cache on node 2. That does'nt happen though. Is it possible to have a configuration wherein, all the instances in the clustered cache are searched for.
I even tried the ClusteredCacheLoader as shown in the configuration below, but that does not make a difference. Isi'nt that what ClusteredCacheLoader is used for??
| --------------------------------------------------------------------------------
| <?xml version="1.0" encoding="UTF-8"?>
|
| <!-- ===================================================================== -->
| <!-- -->
| <!-- Sample TreeCache Service Configuration -->
| <!-- -->
| <!-- ===================================================================== -->
|
| <server>
|
| <classpath codebase="./lib" archives="jbosscache-core.jar, jboss-common-core.jar, jgroups.jar"/>
| <!-- ==================================================================== -->
| <!-- Defines TreeCache configuration -->
| <!-- ==================================================================== -->
|
| <mbean code="org.jboss.cache.TreeCache"
| name="jboss.cache:service=TreeCache">
|
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <!--
| Configure the TransactionManager
| -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.transaction.DummyTransactionManagerLookup
| </attribute>
|
| <!--
| Node locking level : SERIALIZABLE
| REPEATABLE_READ (default)
| READ_COMMITTED
| READ_UNCOMMITTED
| NONE
| -->
| <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
|
| <!--
| Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
| -->
| <attribute name="CacheMode">REPL_SYNC</attribute>
|
| <!--
| Just used for async repl: use a replication queue
| -->
| <attribute name="UseReplQueue">false</attribute>
|
| <!--
| Replication interval for replication queue (in ms)
| -->
| <attribute name="ReplQueueInterval">0</attribute>
|
| <!--
| Max number of elements which trigger replication
| -->
| <attribute name="ReplQueueMaxElements">0</attribute>
|
| <!-- Name of cluster. Needs to be the same for all TreeCache nodes in a
| cluster in order to find each other.
| -->
| <attribute name="ClusterName">JBossCache-Cluster</attribute>
|
| <attribute name="ClusterConfig">
| <config>
| <!-- 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".
| The mcast_addr and mcast_port should be different from the cluster address and port to avoid contention.
| -->
| <!-- 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="224.10.10.10" mcast_port="45566"
| ip_ttl="64" 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" bind_addr="127.0.0.1" bind_port="5544" />
| <PING timeout="2000" num_initial_members="3"
| up_thread="false" down_thread="false"/>
| <MERGE2 min_interval="10000" max_interval="20000"/>
| <!-- <FD shun="true" up_thread="true" down_thread="true" />-->
| <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"/>
| </config>
| </attribute>
|
| <!--
| Whether or not to fetch state on joining a cluster
| -->
| <attribute name="FetchStateOnStartup">true</attribute>
|
| <!--
| The max amount of time (in milliseconds) we wait until the
| initial state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment
| -->
| <attribute name="InitialStateRetrievalTimeout">5000</attribute>
|
| <!--
| The max amount of time (in milliseconds) we wait until the
| state (ie. the contents of the cache) are retrieved from
| existing members in a clustered environment
| -->
| <attribute name="StateRetrievalTimeout">20000</attribute>
|
| <!--
| Number of milliseconds to wait until all responses for a
| synchronous call have been received.
| -->
| <attribute name="SyncReplTimeout">20000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="CacheLoaderConfig" replace="false">
| <config>
| <cacheloader>
| <class>org.jboss.cache.loader.ClusteredCacheLoader</class>
| <properties>
| timeout=15000
| </properties>
| </cacheloader>
| </config>
| </attribute>
| </mbean>
| </server>
| ------------------------------------------------------------------------------------
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204379#4204379
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204379
17 years, 3 months
[Installation, Configuration & DEPLOYMENT] - Re: Copy JBOSS
by PeterJ
If you have both startup.sh and run.sh, then I do not know what you have. I looked at the run.sh for JBoss AS 3.2.6 and it has this id line:
### $Id: run.sh,v 1.9.2.7 2004/12/15 16:47:36 starksm Exp $ ###
Yours is even older, so I suspect that your run.sh from JBoss AS 3.2.6.
To further determine what you have, what directories are at the same level as the bin directory? In other words, if you are in the bin directory, what is the response from 'ls -al ..'?
I looked back on your earlier posts - you stated that you are move you apps to a new JBoss AS setup. So my question to you is, what did you install? What was the name of the zip tor tag.gz file that you unpacked, and where di you get it from? That should solve the question of what you are using.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204375#4204375
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204375
17 years, 3 months