July 2011 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1523) JBoss Cache MBean print* operations return Object's toString()

by Ondrej Žižka (JIRA)

JBoss Cache MBean print* operations return Object's toString() -------------------------------------------------------------- Key: JBCACHE-1523 URL: https://jira.jboss.org/jira/browse/JBCACHE-1523 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ondrej Žižka Assignee: Manik Surtani Priority: Minor 1) Run EAP 5, all config 2) Go to JMX console, jboss.cache:config=ha-partition,service=Cache 3) Invoke print* operations. Cache details: "/ null", as HTML /  null<br/> "Print configuration" returns only java.lang.Object's toString(), e.g. org.jboss.cache.config.Configuration@af91c6fa etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1410) Cache loaders that use StripedLock do not adequately lock root node when the root node is first added.

by Manik Surtani (JIRA)

Cache loaders that use StripedLock do not adequately lock root node when the root node is first added. ------------------------------------------------------------------------------------------------------ Key: JBCACHE-1410 URL: https://jira.jboss.org/jira/browse/JBCACHE-1410 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.0.0.GA Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 3.0.0.GA, 2.X See detail on the forum post. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

4
12
0 / 0

[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

12 years, 7 months

2
5
0 / 0

[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

12 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1601) cache.getNode can delete data when using a passivation cache loader

by Dennis Reed (JIRA)

cache.getNode can delete data when using a passivation cache loader ------------------------------------------------------------------- Key: JBCACHE-1601 URL: https://issues.jboss.org/browse/JBCACHE-1601 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.5.GA Reporter: Dennis Reed Assignee: Dennis Reed When cache.getNode loads a passivated node, the data is not loaded, but it does trigger an eviction event. When eviction then passivates the node again, the data is overwritten. Similar to JBCACHE-825. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1602) NodeSPI.isDataLoaded is false for new node with optimistic locking

by Dennis Reed (JIRA)

NodeSPI.isDataLoaded is false for new node with optimistic locking ------------------------------------------------------------------ Key: JBCACHE-1602 URL: https://issues.jboss.org/browse/JBCACHE-1602 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 3.2.5.GA Reporter: Dennis Reed Assignee: Dennis Reed The following prints "true" with MVCC or Pessimistic locking, but "false" with Optimistic. cache.put ( fqn, key, test ); NodeSPI n = (NodeSPI)cache.getNode ( fqn ); System.out.println ( n.isDataLoaded() ); -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1596) Initial state transfer with more than 200, 000 nodes deadlock on eviction queue

by Dennis Reed (JIRA)

Initial state transfer with more than 200,000 nodes deadlock on eviction queue ------------------------------------------------------------------------------ Key: JBCACHE-1596 URL: https://issues.jboss.org/browse/JBCACHE-1596 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani When the cache has more than 200,000 entries, state transfer deadlocks on the joining node, due to filling up and blocking the eviction queue before the eviction thread has been started. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
5
0 / 0

JBoss Cache Data Source issue with Database password Change !!

by Bh, Guruprasad (NSN - IN/Bangalore)

Hi All, Currently we are using the JBoss Cache processor in our product as part of Service Mix which is a JBI component !! We are facing the below issue related to the password change when using the Jboss Cache Processor !! When we start the Service Mix, it will intaiate the cache object with the datasource configured in the XML, but now if someone changes the oracle password in between my cache data source needs to be get refreshed/recreated automatically in the run time without restarting the service mix. But I am not able to do this, whenever there is a change in oracle DB password the connection will fail because of wrong user name !! So does anyone knows how to handle this as part of Jboss Cache ? Or How to fetch the datasource object from the cache object available to update with the new password ? Please let me know your answers as soon as possible !! Regards Guruprasad BH

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1434) Fix UnitTestCacheFactory extractTestName method

by Dominik Pospisil (JIRA)

Fix UnitTestCacheFactory extractTestName method ----------------------------------------------- Key: JBCACHE-1434 URL: https://jira.jboss.org/jira/browse/JBCACHE-1434 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Dominik Pospisil Assignee: Dominik Pospisil UnitTestCacheFactory uses stack trace introspection to retreive executed test class name. It does not work if the factory method is called from a seperclass of test class. Find other way around to retrieve test class. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
3
0 / 0

[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

12 years, 10 months

3
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues July 2011