1 2 Previous Next 22 Replies Latest reply on Jun 23, 2008 10:21 AM by Manik Surtani

    Exception when a cluster node joins under load

    Dmitriy Setrakyan Newbie


      I have cache configured with INVALIDATION_SYNC policy and get the following error when a 2nd cluster node starts up under load:

      java.lang.IllegalStateException: Cache not in STARTED state!
       at org.jboss.cache.CacheImpl.invokeMethod(CacheImpl.java:3929)
       at org.jboss.cache.CacheImpl._replicate(CacheImpl.java:2853)
       at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
       at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
       at java.lang.reflect.Method.invoke(Method.java:585)
       at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
       at org.jboss.cache.marshall.InactiveRegionAwareRpcDispatcher.handle(InactiveRegionAwareRpcDispatcher.java:77)
       at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:624)
       at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:533)
       at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:365)
       at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:744)
       at org.jgroups.JChannel.up(JChannel.java:1148)
       at org.jgroups.mux.Multiplexer$Task.run(Multiplexer.java:1041)
       at org.jgroups.mux.Multiplexer$ExecuteTask.run(Multiplexer.java:1065)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
       at java.lang.Thread.run(Thread.java:595)

      Any help is appreciated.

      Here is my cache configuration just in case:
       <mbean code="org.jboss.cache.jmx.CacheJmxWrapper"
       The JMX object name of the service that defines the JGroups multiplexer.
       In JBoss AS 5.0 this service is normally defined in the jgroups-multiplexer.sar.
       This XML attribute can only be handled by the JBoss AS MBean deployment
       services; if it is included in a file passed to a CacheFactory the factory's
       creation of the cache will fail. Inside JBoss AS, the attribute should be
       specified using the "depends optional-attribute-name" syntax shown below.
       Inside the AS if this attribute is defined, an instance of
       org.jgroups.jmx.JChannelFactoryMBean will be injected into the
       CacheJmxWrapper which will use it to obtain a multiplexed JGroups channel.
       The configuration of the channel will be that associated with MultiplexerStack.
       The ClusterConfig attribute will be ignored.
       <depends optional-attribute-name="MultiplexerService"
       Following attributes specify using of multiplexer and protocols stack name.
       <attribute name="MultiplexerStack">grid.jgroups.stack</attribute>
       <attribute name="UsingMultiplexer">true</attribute>
       Node locking isolation level : SERIALIZABLE, REPEATABLE_READ (default),
       READ_COMMITTED, READ_UNCOMMITTED, and NONE. Note that this is ignored
       if NodeLockingScheme is OPTIMISTIC. Case doesn't matter.
       See documentation on Transactions and Concurrency for more details.
       <attribute name="IsolationLevel">READ_COMMITTED</attribute>
       <!-- Indicates whether state should be fetched on startup. -->
       <attribute name="FetchInMemoryState">false</attribute>
       This replication mode is cheapest with data affinity.
       <attribute name="CacheMode">INVALIDATION_SYNC</attribute>
       Name of cluster. Needs to be the same for all nodes in a cluster in order
       for them to communicate with each other.
       <attribute name="ClusterName">JBossCache-Cluster</attribute>
       Time in milliseconds to wait for state retrieval. This should be longer than
       LockAcquisitionTimeout as the node providing state may need to wait that
       long to acquire necessary read locks on the cache. This property is dynamic.
       <attribute name="StateRetrievalTimeout">20000</attribute>
       For synchronous replication: time in milliseconds to wait until replication
       acks have been received from all nodes in the cluster. It is usually best
       that this is greater than LockAcquisitionTimeout . This property is dynamic.
       <attribute name="SyncReplTimeout">15000</attribute>
       Time in milliseconds to wait for a lock to be acquired. If a lock cannot be
       acquired an exception will be thrown. This property is dynamic.
       <attribute name="LockAcquisitionTimeout">15000</attribute>
       Specific eviction policy configurations. This is LRU.
       <attribute name="EvictionPolicyConfig">
       <attribute name="wakeUpIntervalSeconds">5</attribute>
       <!-- This defaults to 200000 if not specified -->
       <attribute name="eventQueueSize">200000</attribute>
       <!-- Name of the DEFAULT eviction policy class. -->
       <attribute name="policyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
       <!-- Cache wide default -->
       <region name="/_default_">
       <attribute name="maxNodes">1000000</attribute>
       <!-- No limit. -->
       <attribute name="timeToLiveSeconds">0</attribute>
       <region name="/novus/data">
       <attribute name="maxNodes">1000000</attribute>
       <!-- No limit. -->
       <attribute name="timeToLiveSeconds">0</attribute>
       <attribute name="CacheLoaderConfig">
       <!-- If passivation is true, only the first cache loader is used; the rest are ignored. -->
       <!-- No preloading. -->
       <!-- Are the cache loaders shared in a cluster? -->
       <!-- Properties to pass in to the cache loader. -->
       <!-- Whether the cache loader writes are asynchronous. -->
       <!-- There is no persistent state for this cacheloader. -->
       <!-- Determines whether this cache loader ignores writes - defaults to false. -->
       <!-- If set to true, purges the contents of this cache loader when the cache starts up. -->
       Defines the cache loader as a singleton store where only the coordinator of the
       cluster will store modifications.
       <!-- If true, singleton store functionality is enabled, defaults to false. -->
       Implementation class for singleton store functionality which must extend
       org.jboss.cache.loader.AbstractDelegatingCacheLoader. Default implementation
       is org.jboss.cache.loader.SingletonStoreCacheLoader.
       Properties and default values for the default singleton store functionality

      Thanks in advance.

        1 2 Previous Next