Yes i use async, i don't use flow control protocol (i don't now if it's supported in this release of JBoss (1.2.4/jgroups 2.2.8), but as you can see in my publisher test class, all 1000 msg (via modulo) i call a sleep of 2000ms (i have test without). What is very strange is, this is not the publisher but the sender which grow up in memory. more strange and more supect for a production release is that the memory never retrieve a "normal" space. ( i mean: ok the JVM has allocate a big space of memory to compute a burst of msg, but when all msg have been send by the publisher (for example i test with 100 000 msg) the memory stay at the same level (and a force gc has no impact).
Today, i try to test with TreeCache aonly (without AOP features). Christophe <?xml version="1.0" encoding="UTF-8"?> | | <!-- ===================================================================== --> | <!-- --> | <!-- Sample TreeCache Service Configuration --> | <!-- --> | <!-- ===================================================================== --> | | <server> | <!-- | | <classpath codebase="./lib" archives="jboss-cache.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.DummyTransactionManagerLookup</attribute> | | <!-- | Isolation 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_ASYNC</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 clusters, in order | to find each other | --> | <attribute name="ClusterName">**TEST**</attribute> | | <!-- JGroups protocol stack properties. Can also be a URL, | e.g. file:/home/bela/default.xml | <attribute name="ClusterProperties"></attribute> | --> | | <attribute name="ClusterConfig"> | <config> | <UDP mcast_send_buf_size="10000000" mcast_port="6667" ucast_recv_buf_size="10000000" | mcast_addr="239.255.8.15" bind_to_all_interfaces="true" loopback="false" mcast_recv_buf_size="10000000" | max_bundle_size="64000" max_bundle_timeout="30" use_incoming_packet_handler="false" | use_outgoing_packet_handler="true" ucast_send_buf_size="10000000" ip_ttl="32" enable_bundling="true" /> | <PING timeout="2000" down_thread="false" num_initial_members="3" /> | <MERGE2 max_interval="10000" down_thread="false" min_interval="5000" /> | <FD_SOCK down_thread="false" /> | <VERIFY_SUSPECT timeout="1500" down_thread="false" /> | <pbcast.NAKACK max_xmit_size="60000" down_thread="false" use_mcast_xmit="true" gc_lag="50" | retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> | <UNICAST timeout="300,600,1200,2400,3600" down_thread="false" /> | <pbcast.STABLE stability_delay="1000" desired_avg_gossip="5000" down_thread="false" max_bytes="250000" /> | <pbcast.GMS print_local_addr="true" join_timeout="3000" down_thread="false" join_retry_timeout="2000" | shun="true" /> | <FC max_credits="1000000" down_thread="false" min_threshold="0.10" /> | <FRAG frag_size="60000" down_thread="false" up_thread="true" /> | <COMPRESS down_thread="false" min_size="500" compression_level="3" up_thread="true" /> | <pbcast.STATE_TRANSFER down_thread="false" up_thread="false" /> | </config> | | </attribute> | | <!-- | Whether or not to fetch state on joining a cluster | --> | <attribute name="FetchStateOnStartup">true</attribute> | <attribute name="CacheLoaderFetchTransientState">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> | | <!-- | 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="LockAcquisitionTimeout">15000</attribute> | | | <!-- Name of the eviction policy class. --> | <attribute name="EvictionPolicyClass"></attribute> | | <!-- | Indicate whether to use marshalling or not. Set this to true if you are running under a scoped | class loader, e.g., inside an application server. Default is "false". | --> | <attribute name="UseMarshalling">false</attribute> | | </mbean> | | | <!-- Uncomment to get a graphical view of the TreeCache MBean above --><!-- | <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView"> | <depends>jboss.cache:service=TreeCache</depends> | <attribute name="CacheService">jboss.cache:service=TreeCache</attribute> | </mbean> | --> | </server> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3898606#3898606 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3898606 ------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ JBoss-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-user
