[JBoss Cache Users] - JBoss 4.2.2 with TreeCache 1.4.1.SP5: nodes, attributes not
by the_olo
Hi!
I have a clustered TreeCache set up on the standard JBoss 4.2.2 GA release (for caching jBPM-BPEL data).
It seems that the contents of the cache are properly replicated only during the initial state transfer - when a node joins the cluster, the logs show:
2009-09-18 13:44:41,932 INFO [org.jboss.cache.TreeCache] received the state (size=1024 bytes)
| 2009-09-18 13:44:41,936 INFO [org.jboss.cache.TreeCache] received the state (size=1024 bytes)
| 2009-09-18 13:44:41,939 INFO [org.jboss.cache.TreeCache] received the state (size=1024 bytes)
| 2009-09-18 13:44:41,942 INFO [org.jboss.cache.TreeCache] received the state (size=1024 bytes)
| 2009-09-18 13:44:41,943 DEBUG [org.jboss.hibernate.jbc.cacheprovider.OptimisticJBCCache] activateCacheRegion(): Region /org/jbpm/graph/def/ProcessDefinition/a
| ctions is already active
| 2009-09-18 13:44:41,945 INFO [org.jboss.cache.TreeCache] received the state (size=1024 bytes)
| 2009-09-18 13:44:41,946 DEBUG [org.jboss.hibernate.jbc.cacheprovider.OptimisticJBCCache] activateCacheRegion(): Region /org/jbpm/graph/def/ProcessDefinition/d
| efinitions is already active
While on the node that supplies the state transfer data, I can see in the logs:
2009-09-18 13:44:41,941 INFO [org.jboss.cache.interceptors.OptimisticNodeInterceptor] read Method _getState; id:19(/org/jbpm/file/def/FileDefinition/processF
| iles, 400, false, false) called - don't know how to handle, passing on!
| 2009-09-18 13:44:41,941 INFO [org.jboss.cache.statetransfer.StateTransferGenerator_140] returning the state for tree rooted in /org/jbpm/file/def/FileDefinit
| ion/processFiles(1024 bytes)
| 2009-09-18 13:44:41,944 INFO [org.jboss.cache.interceptors.OptimisticNodeInterceptor] read Method _getState; id:19(/org/jbpm/bpel/graph/scope/Scope/onEvents,
| 400, false, false) called - don't know how to handle, passing on!
| 2009-09-18 13:44:41,944 INFO [org.jboss.cache.statetransfer.StateTransferGenerator_140] returning the state for tree rooted in /org/jbpm/bpel/graph/scope/Sco
| pe/onEvents(1024 bytes)
| 2
During normal operation, however, it seems that cache contents aren't replicated.
I'm looking at the attributes of the "jboss.cache:service=MyTreeCache" MBean.
When I execute a business process on node A, then I can see rapid growth of the "NumberOfAttributes" and "NumberOfNodes" attribute values (until the cache gets saturated).
But the expected synchronous growth on node B doesn't happen. When I do the same on node B, the counts rise on that node, but node A remains uninfluenced.
So I suspect that cache replication does not work. Or maybe it should work that way? Maybe I am looking at the wrong MBean attributes?
Here's the configuration of my TreeCache:
| <?xml version="1.0" encoding="UTF-8"?>
| <server>
| <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=MyTreeCache">
| <depends>jboss:service=Naming</depends>
| <depends>jboss:service=TransactionManager</depends>
|
| <!-- Configure the TransactionManager -->
| <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup
| </attribute>
|
| <!--
| Node locking scheme :
| PESSIMISTIC (default)
| OPTIMISTIC
| -->
| <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
|
| <!--
| Node locking isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE
| (ignored if NodeLockingScheme is OPTIMISTIC)
| -->
| <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
|
| <!--
| Valid modes are LOCAL REPL_ASYNC REPL_SYNC INVALIDATION_ASYNC INVALIDATION_SYNC
| -->
| <attribute name="CacheMode">REPL_ASYNC</attribute>
|
| <!-- Whether each interceptor should have an mbean
| registered to capture and display its statistics. -->
| <!-- javax.management.AttributeNotFoundException: Attribute 'UseInterceptorMbeans' is not writable -->
| <!--
| <attribute name="UseInterceptorMbeans">true</attribute>
| -->
|
| <attribute name="UseRegionBasedMarshalling">true</attribute>
| <attribute name="InactiveOnStartup">true</attribute>
|
| <!-- Name of cluster. Needs to be the same for all clusters, in order
| to find each other -->
| <attribute name="ClusterName">${jboss.partition.name:DefaultPartition}-MyTreeCache
| </attribute>
|
| <attribute name="ClusterConfig">
| <config>
| <UDP mcast_addr="${jboss.partition.udpGroup:228.1.4.5}" mcast_port="${jboss.hapartition.mcast_port:48566}"
| tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" mcast_recv_buf_size="25000000"
| mcast_send_buf_size="640000" loopback="false" discard_incompatible_packets="true" enable_bundling="false"
| max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="true"
| use_outgoing_packet_handler="false" ip_ttl="${jgroups.udp.ip_ttl:2}" down_thread="false" up_thread="false" />
| <PING timeout="2000" down_thread="false" up_thread="false" num_initial_members="3" />
| <MERGE2 max_interval="100000" down_thread="false" up_thread="false" min_interval="20000" />
| <FD_SOCK down_thread="false" up_thread="false" />
| <FD timeout="10000" max_tries="5" down_thread="false" up_thread="false" shun="true" />
| <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false" />
| <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800"
| down_thread="false" up_thread="false" discard_delivered_msgs="true" />
| <UNICAST timeout="300,600,1200,2400,3600" down_thread="false" up_thread="false" />
| <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" down_thread="false" up_thread="false"
| max_bytes="400000" />
| <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" up_thread="false"
| join_retry_timeout="2000" shun="true" view_bundling="true" />
| <FRAG2 frag_size="60000" down_thread="false" up_thread="false" />
| <pbcast.STATE_TRANSFER down_thread="false" up_thread="false" use_flush="false" />
| </config>
| </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>
|
| <!-- Number of milliseconds to wait until all responses for a
| synchronous call have been received.
| -->
| <attribute name="SyncReplTimeout">10000</attribute>
|
| <!-- Max number of milliseconds to wait for a lock acquisition -->
| <attribute name="LockAcquisitionTimeout">15000</attribute>
|
| <!-- Name of the eviction policy class. -->
| <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
|
| <!-- Specific eviction policy configurations. This is LRU -->
| <attribute name="EvictionPolicyConfig">
| <config>
| <attribute name="wakeUpIntervalSeconds">5</attribute>
| <!-- Cache wide default -->
| <region name="/_default_">
| <attribute name="maxNodes">5000</attribute>
| <attribute name="timeToLiveSeconds">1000</attribute>
| <!-- Maximum time an object is kept in cache regardless of idle time -->
| <attribute name="maxAgeSeconds">120</attribute>
| </region>
|
| <region name="/org/jboss/data">
| <attribute name="maxNodes">5000</attribute>
| <attribute name="timeToLiveSeconds">1000</attribute>
| </region>
|
| <region name="/org/jboss/test/data">
| <attribute name="maxNodes">5</attribute>
| <attribute name="timeToLiveSeconds">4</attribute>
| </region>
|
| <region name="/org/jbpm/graph">
| <attribute name="maxNodes">5000</attribute>
| <!-- 259200 secs = 3 * 24 hours in order to survive the weekend: -->
| <attribute name="timeToLiveSeconds">259200</attribute>
| </region>
| <region name="/org/jbpm/bpel/graph">
| <attribute name="maxNodes">5000</attribute>
| <!-- 259200 secs = 3 * 24 hours in order to survive the weekend: -->
| <attribute name="timeToLiveSeconds">259200</attribute>
| </region>
| <region name="/org/jbpm">
| <attribute name="maxNodes">10000</attribute>
| <attribute name="timeToLiveSeconds">7200</attribute>
| <attribute name="maxAgeSeconds">259200</attribute>
| </region>
|
| </config>
| </attribute>
| </mbean>
| </server>
|
| I've tried both with REPL_ASYNC and REPL_SYNC CacheMode and the result is the same.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256102#4256102
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256102
16 years, 9 months
[JBoss Tools Users] - Re: how to get xx.pages.xml files to auto reload...
by max.andersen＠jboss.com
"deanhiller" wrote : I find myself needing to restart the server every time I change xxx.pages.xml files even though I read that jboss tools supports hot redeploy of those files. How do I configure jboss so that seam reloads just the pages files(and hopefully not the entire app)???
|
JBoss Tools doesn't do anything specific for pages.xml beyond making sure the file is copied to the deployment when you edit it.
If Seam supports it then it should work - but I must admit I haven't tried it for that specific feature. Where did you read about it ?
anonymous wrote :
| Also, I read about the dev directory and deployment to that dir causes seam to reload in just the changed components(including annotations), BUT if I do that, won't tomcat then redeploy the entire app.
Why should tomcat reload the app because Seam dynamically reload classes from the /dev folder ?
anonymous wrote : This sounds like it defeats the purpose as tomcat redeploys the entire app on every class file change unless you set up the context.xml file but then your files are not copied to the target dirs.
I don't understand "but then your files are not copied to the target dirs" ? What does that mean ? (btw. tomcat eclipse integration is not done by jboss tools, its done by WTP)
About your other question since the files are in /dev and not in /classes then tomcat doesn't know about them so it shouldn't care.
anonymous wrote :
| ie. how to configure this as well even though, it is very annoying that it has to be a dev dir....would be much nicer if the components.xml had a configure option I could turn on and off instead(that is probably more a seam forum question I guess though).
|
Yup, but if the .class are in the "normal" classpath location then Seam wouldn't be able to do anything - then it becomes the VM or the container's job.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256095#4256095
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256095
16 years, 9 months
[Installation, Configuration & Deployment] - Re: Jboss 4.2.3 GA upgrade
by rasa
I have started now it is from cmd using run.bat. One jar file was missing and that i have added in lib of default directory. See the error
|
| 12:33:47,984 ERROR [MainDeployer] Could not create deployment: file:/E:/jboss-4.
| 2.3.GA/jboss-4.2.3.GA/server/default/deploy/application.jar
| org.jboss.deployment.DeploymentException: Verification of Enterprise Beans faile
| d, see above for error messages.
| at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:610)
| at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
| java:39)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
| at java.lang.reflect.Method.invoke(Method.java:592)
| at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatch
| er.java:155)
| at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
| at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractIntercept
| or.java:133)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelM
| BeanOperationInterceptor.java:142)
| at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor
| .java:97)
| at org.jboss.system.InterceptorServiceMBeanSupport.invokeNext(Intercepto
| rServiceMBeanSupport.java:238)
| at org.jboss.wsf.container.jboss42.DeployerInterceptor.create(DeployerIn
| terceptor.java:76)
| at org.jboss.deployment.SubDeployerInterceptorSupport$XMBeanInterceptor.
| create(SubDeployerInterceptorSupport.java:180)
| at org.jboss.deployment.SubDeployerInterceptor.invoke(SubDeployerInterce
| ptor.java:91)
| at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
| at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.
| java:264)
| at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
| at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
| at $Proxy32.create(Unknown Source)
| at org.jboss.deployment.MainDeployer.create(MainDeployer.java:969)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:818)
| at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
| at sun.reflect.GeneratedMethodAccessor20.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
| sorImpl.java:25)
In my application i amusing ejb2.0 and java 1.5. Is it because of this.
Please give a suggestion.
Regards
Rasa.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4256083#4256083
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4256083
16 years, 9 months