[JBoss JIRA] Created: (JBCACHE-1600) CacheJmxWrapper ignores ClusterConfig attribute
by Dennis Reed (JIRA)
CacheJmxWrapper ignores ClusterConfig attribute
-----------------------------------------------
Key: JBCACHE-1600
URL: https://issues.jboss.org/browse/JBCACHE-1600
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JMX
Affects Versions: 3.2.5.GA
Reporter: Dennis Reed
Assignee: Dennis Reed
Attachments: test-service.xml
When creating a cache using the CacheJmxWrapper:
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="test:service=TreeCache">
<attribute name="CacheMode">REPL_SYNC</attribute>
<attribute name="ClusterName">Test</attribute>
<attribute name="ClusterConfig">
<config>
<TCP start_port="12345"
the ClusterConfig section is ignored, and a default JGroups configuration is used.
The root cause is CacheJmxWrapper#setClusterConfig parses the contents of <ClusterConfig>,
but doesn't save it, and always sets the result to null.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBCACHE-1585) JBossCache eviction thread creating a Timer without making the new thread a daemon thread
by Mats Henrikson (JIRA)
JBossCache eviction thread creating a Timer without making the new thread a daemon thread
-----------------------------------------------------------------------------------------
Key: JBCACHE-1585
URL: https://jira.jboss.org/browse/JBCACHE-1585
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.1.SP13
Reporter: Mats Henrikson
Assignee: Manik Surtani
There is a problem where the class org.jboss.cache.eviction.RegionManager.EvictionTreeCacheListener.cacheStarted(), line 499:
{code}
evictionThread_ = new Timer();
{code}
Since the new Timer() is created without telling it that it is a daemon thread this Timer thread will actually cause the JVM to not exit when the main() method of the application finishes - it makes it necessary to call System.exit() to shut the JVM down.
Since this is the thread that periodically runs the specified eviction policy there is no need for it to cause the JVM to stay running - it's up to the developer to say if the JVM should stay running or not, not JBossCache.
The line should be changed to something like:
{code}
evictionThread_ = new Timer(true);
{code}
in order to specify that this is a daemon thread. (At the same time it would also be good if the Timer is passed a thread name like for instance "JBossCache Eviction Thread".)
Please see the JDK docs for more info:
http://java.sun.com/j2se/1.5.0/docs/api/java/util/Timer.html#Timer(java.l...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 2 months
[JBoss JIRA] Created: (JBCACHE-1592) org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster
by l jw (JIRA)
org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster
--------------------------------------------------------------------------------------------------
Key: JBCACHE-1592
URL: https://jira.jboss.org/browse/JBCACHE-1592
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Locking
Affects Versions: 3.2.5.GA
Environment: windows os,cluster node in one machine.
Reporter: l jw
Assignee: Manik Surtani
Priority: Blocker
When used in cluster,the following exception is throw frequently:
org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/courseClass/360/male] after [5000] milliseconds for requestor [GlobalTransaction:<172.18.73.162:3430>:1843]! Lock held by [GlobalTransaction:<172.18.73.162:3428>:6416]
at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101)
at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:150)
at org.jboss.cache.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:107)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:501)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:388)
at org.jboss.cache.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:134)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
at org.jboss.cache.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:140)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPrepareCommand(InvocationContextInterceptor.java:106)
at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
at org.jboss.cache.interceptors.InterceptorChain.invokeRemote(InterceptorChain.java:316)
at org.jboss.cache.commands.remote.ReplicateCommand.processSingleCommand(ReplicateCommand.java:139)
at org.jboss.cache.commands.remote.ReplicateCommand.perform(ReplicateCommand.java:115)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:319)
at org.jboss.cache.marshall.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:246)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:545)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:368)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:775)
at org.jgroups.JChannel.up(JChannel.java:1336)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:486)
at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:319)
at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:820)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
at org.jgroups.protocols.FD.up(FD.java:284)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:307)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
at org.jgroups.protocols.Discovery.up(Discovery.java:264)
at org.jgroups.protocols.PING.up(PING.java:273)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1273)
at org.jgroups.protocols.TP.access$100(TP.java:49)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1826)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1805)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
and following is my config:
<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.2">
<locking isolationLevel="REPEATABLE_READ"
lockParentForChildInsertRemove="false"
lockAcquisitionTimeout="5000"
nodeLockingScheme="mvcc"
writeSkewCheck="true"
useLockStriping="true"
concurrencyLevel="10000"/>
<clustering mode="replication" clusterName="JBossCache-cluster">
<stateRetrieval timeout="5000" fetchInMemoryState="false" nonBlocking="false"/>
<sync replTimeout="5000"/>
<jgroupsConfig>
<UDP discard_incompatible_packets="true" enable_bundling="false" enable_diagnostics="false" ip_ttl="2"
loopback="false" max_bundle_size="64000" max_bundle_timeout="30" mcast_addr="224.0.0.1"
mcast_port="45588" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000"
oob_thread_pool.enabled="true" oob_thread_pool.keep_alive_time="10000" oob_thread_pool.max_threads="4"
oob_thread_pool.min_threads="1" oob_thread_pool.queue_enabled="true"
oob_thread_pool.queue_max_size="10"
oob_thread_pool.rejection_policy="Run" thread_naming_pattern="pl" thread_pool.enabled="true"
thread_pool.keep_alive_time="30000" thread_pool.max_threads="25" thread_pool.min_threads="1"
thread_pool.queue_enabled="true" thread_pool.queue_max_size="10" thread_pool.rejection_policy="Run"
tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" use_concurrent_stack="true"
use_incoming_packet_handler="true"/>
<PING num_initial_members="3" timeout="2000"/>
<MERGE2 max_interval="30000" min_interval="10000"/>
<FD_SOCK/>
<FD max_tries="5" shun="true" timeout="10000"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK discard_delivered_msgs="true" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800"
use_mcast_xmit="false"/>
<UNICAST timeout="300,600,1200,2400,3600"/>
<pbcast.STABLE desired_avg_gossip="50000" max_bytes="400000" stability_delay="1000"/>
<pbcast.GMS join_timeout="5000" print_local_addr="true" shun="false" view_ack_collection_timeout="5000"
view_bundling="true"/>
<FRAG2 frag_size="60000"/>
<pbcast.STREAMING_STATE_TRANSFER/>
<pbcast.FLUSH timeout="0"/>
</jgroupsConfig>
</clustering>
</jbosscache>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
Memory leak in JBossCache
by Nishi Kant
Hi All,
I'm using JBoss cache in my project, recently I have enabled replication. While putting the system through the load of 9K users with each user modifying the state every 10 sec found that there is sharp increase in amount of memory being consumed by the process. After few hours process raised out of Memory from old generation. Memory histogram of the process shows following two classes taking lots of heap space.
1: 7023853 224763296 java.lang.ThreadLocal$ThreadLocalMap$Entry
2: 7022005 168528120 java.util.concurrent.locks.ReentrantReadWriteLock$Sync$HoldCounter
I'm have 3 nodes in cluster. I'm using async replication and my configuration file is as follows:-
<?xml version="1.0" encoding="UTF-8"?>
<server>
<mbean code="org.jboss.cache.jmx.CacheJmxWrapper" name="jboss.cache:service=Cache">
<attribute name="TransactionManagerLookupClass">
org.jboss.cache.transaction.DummyTransactionManagerLookup
</attribute>
<attribute name="IsolationLevel">REPEATABLE_READ</attribute>
<attribute name="LockParentForChildInsertRemove">false</attribute>
<attribute name="CacheMode">REPL_ASYNC</attribute>
<attribute name="useLockStriping">false</attribute>
<attribute name="UseReplQueue">false</attribute>
<attribute name="ReplQueueInterval">0</attribute>
<attribute name="ReplQueueMaxElements">0</attribute>
<attribute name="InactiveOnStartup">true</attribute>
<attribute name="ClusterName">TreeCache-Cluster</attribute>
<attribute name="ClusterProperties"></attribute> -->
<attribute name="ClusterConfig">
<config>
<UDP mcast_addr="228.1.2.3" mcast_port="12345" 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"
bind_addr="192.168.1.19"/>
<PING timeout="2000" num_initial_members="3" up_thread="false" down_thread="false" />
<MERGE2 min_interval="10000" max_interval="20000" />
<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" />
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000" 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" />
</config>
</attribute>
<!-- Whether or not to fetch state on joining a cluster -->
<!-- <attribute name="FetchStateOnStartup">false</attribute>
<attribute name="FetchInMemoryState">false</attribute> -->
<attribute name="InitialStateRetrievalTimeout">50000</attribute>
<attribute name="SyncReplTimeout">70000</attribute>
<!-- attribute name="LockAcquisitionTimeout">50000</attribute -->
<!-- Name of the eviction policy class. -->
<attribute name="EvictionPolicyClass" />
</mbean>
</server>
Any help will be highly appreciated.
Thanks,
Nishi
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
13 years, 8 months