[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
Have you read http://wiki.jboss.org/wiki/Wiki.jsp?page=FDVersusFD_SOCK ? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4134816#4134816 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4134816 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
I read some articles about FD ,but I can't find a configration that ompletely avoid this problem. I tried to cope with this question by modify the emberlist or reconnecting the channel. But soon find them doesn't work . Finally I recreate the channel and solved the problem to solve this problem. If somebody have good ideas about FD configration , just reply to this post , I'll be very appreciate . Our next version of product may take this solution. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4133898#4133898 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4133898 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
anonymous wrote : Can I delete a member from one cache's member view (delete the other member who has essentially died)? If it is, How can i do it? That's not the way to go. It is JGroups's failure detection protocol(FD) that should manage member removal/addition. I suggest you read /tune the Failure Detection section in the JGroups manual View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4133653#4133653 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4133653 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
what is the configuration where this appears? (JBossCache version, cache config file) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4132935#4132935 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4132935 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
I am sorry the flags in the config content is missings when showed in the page. Now I have another idea. Can I delete a member from one cache's member view (delete the other member who has essentially died)? If it is, How can i do it? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4133065#4133065 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4133065 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBossCache] - Re: Is v1.4.1 completely compatible with v1.4.0
Fllowing is the config file, thanks to mircea.markus. ?xml version=1.0 encoding=UTF-8? !-- = -- !-- -- !-- Sample TreeCache Service Configuration -- !-- -- !-- = -- !-- -- !-- Defines TreeCache configuration -- !-- -- jboss:service=Naming jboss:service=TransactionManager org.jboss.cache.DummyTransactionManagerLookup READ_UNCOMMITTED INVALIDATION_ASYNC TestCluster_WY_2664-- UDP mcast_addr=228.1.3.5 mcast_port=45577 ip_ttl=64 ip_mcast=true mcast_send_buf_size=15 mcast_recv_buf_size=8 ucast_send_buf_size=15 ucast_recv_buf_size=8 loopback=true/ PING timeout=2000 num_initial_members=3 up_thread=false down_thread=false/ MERGE2 min_interval=1 max_interval=2/ FD shun=true up_thread=true down_thread=true/ VERIFY_SUSPECT timeout=1500 up_thread=false down_thread=false/ pbcast.NAKACK gc_lag=50 retransmit_timeout=600,1200,2400,4800 up_thread=false down_thread=false/ pbcast.STABLE desired_avg_gossip=2 up_thread=false down_thread=false/ UNICAST timeout=600,1200,2400 window_size=100 min_threshold=10 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=false down_thread=false/ 2 15000 !-- Max number of milliseconds to wait for a lock acquisition -- 1 !--Name of the eviction policy class. -- org.jboss.cache.eviction.LRUPolicy !--Specific eviction policy configurations. This is LRU -- 5 !--Cache wide default -- 1 0 !--if passivation is true, only the first cache loader is used; the rest are ignored -- false !--comma delimited FQNs to preload -- / !--are the cache loaders shared in a cluster? -- false !--we can now have multiple cache loaders, which get chained -- !--the 'cacheloader' element may be repeated -- com.primeton.eos.wf.service.instpool.treecache.optimize.EOSCacheLoaderOptimize !--same as the old CacheLoaderConfig attribute -- !-- cache.jdbc.driver=com.mysql.jdbc.Driver cache.jdbc.url=jdbc:mysql://localhost:3306/jbossdb cache.jdbc.user=root cache.jdbc.password= -- !--whether the cache loader writes are asynchronous -- false !--only one cache loader in the chain may set fetchPersistentState to true. An exception is thrown if more than one cache loader sets this to true. -- true !--determines whether this cache loader ignores writes -defaults to false. -- false !--if set to true, purges the contents of this cache loader when the cache starts up. Defaults to false. --
