Caches being combined

I am having a problem. When I deploy two different ear files, each with a 
different mbean of class org.jboss.cache.TreeCache, they show up in both of the 
mbean?s printDetails() request as follows:

/control
/WebCache
SystemWebCache: [{systemName=, label=}, {label=ARBOR Pool,
BuiltWebCache: Built WebCache Fri Feb 04 07:38:40 PST 2005

/eso
/WebCache
EsoTypeWebCache: [{esoTypeName=, esoTypeId=}, 
BuiltWebCache: Built WebCache Fri Feb 04 07:38:34 PST 2005
EsoManagerEngineerWebCache: [{name=, engineerId=ALL}, 
ViewWebCache: [{value=Requires Attention, keyCode=ACTIVE}, 
LateReasonWebCache: [{value=, keyCode=}, {value=Customer, 


Here is the common mbean definition, the only differnece bewteen the two is the 
mbean name:

   

      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

      <!-- Just used for async repl: use a replication queue -->
      false

      <!-- Replication interval for replication queue (in ms) -->
      0

      <!-- Max number of elements which trigger replication -->
      0

      <!-- Name of cluster. Needs to be the same for all clusters, in order
           to find each other -->
      TreeCache-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 
-->
            <!-- 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.189" 
                           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"/>
            <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"/>
         
      

      <!-- Max number of entries in the cache. If this is exceeded, the
           eviction policy will kick some entries out in order to make
           more room -->
      5000

      <!-- Whether or not to fetch state on joining a cluster -->
      true

      <!-- 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 -->
      5000

      <!-- Number of milliseconds to wait until all responses for a
           synchronous call have been received. -->
      10000

      <!-- Max number of milliseconds to wait for a lock acquisition -->
      15000

      <!-- Max number of milliseconds we hold a lock (not currently
           implemented) -->
      60000

      <!-- Name of the eviction policy class. -->
      org.jboss.cache.eviction.LRUPolicy
      <!-- Specific eviction policy configurations. This is LRU -->
      
         
            5
            
               5000
               0
            
            <!-- Cache wide default -->
            
               5000
               3600
            
         
      
   

Other mbean name:

   


Shouldn?t they appear in only their own printDetails()? How do I get them to be 
sepperate? It seems that because of this, the EvictionPolicy?s get mixed up.

Any ideas? Thanks!

View the original post : 
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3865224#3865224

Reply to the post : 
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3865224


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
JBoss-Development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to