July 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1525) Cache.removeNode does not remove node when buddies are configured and called on instance which does not contains the node.

by Jaroslaw Lewandowski (JIRA)

Cache.removeNode does not remove node when buddies are configured and called on instance which does not contains the node. -------------------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1525 URL: https://jira.jboss.org/jira/browse/JBCACHE-1525 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 3.0.0.GA Reporter: Jaroslaw Lewandowski Assignee: Manik Surtani When tried to remove node from cache instance which had one budy and the budy on the other side possesed all the data it looks like the node still exists in the cluster. The following test does shows the problem. {code:java} @Test public void stealEachOtherData() throws Exception { Cache<Object,Object> cacheOne = PojoCacheFactory.createCache("configuration/test-jgroups-budies.xml").getCache(); Cache<Object, Object> cacheTwo = PojoCacheFactory.createCache("configuration/test-jgroups-budies.xml").getCache(); Fqn fqn = Fqn.fromString("/test/blah"); String key = "key"; for (int i = 0; i < 100; i++) { String value = "Value"+i; cacheOne.put(fqn, key, value); Node<Object,Object> node; long timeOut = 3000L; node = assertNotNullWithTimeOut(cacheTwo, fqn, timeOut); assertEquals(value, node.get(key)); node = assertNotNullWithTimeOut(cacheOne, fqn, timeOut); assertEquals(value, node.get(key)); _log.debug("BEFORE REMOVE"); cacheTwo.removeNode(fqn); assertNull(cacheOne.getNode(fqn)); assertNull(cacheTwo.getNode(fqn)); } } private Node<Object, Object> assertNotNullWithTimeOut(Cache<Object, Object> cacheTwo, Fqn fqn, long timeOut) throws InterruptedException { Node<Object, Object> node = null; long start = System.currentTimeMillis(); do { node = cacheTwo.getNode(fqn); Thread.sleep(50l); } while (node == null && (System.currentTimeMillis() - start < timeOut)); assertNotNull(node); return node; } {code} here is the configuration {code:xml} <?xml version="1.0" encoding="UTF-8" ?> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.0"> <locking isolationLevel="REPEATABLE_READ" lockParentForChildInsertRemove="false" lockAcquisitionTimeout="20000" nodeLockingScheme="mvcc" writeSkewCheck="false" concurrencyLevel="500"/> <clustering mode="replication" clusterName="TestDigitalVault"> <stateRetrieval timeout="15000" fetchInMemoryState="false"/> <sync replTimeout="15000"/> <buddy enabled="true" communicationTimeout="3000"> <dataGravitation auto="true" removeOnFind="true" searchBackupTrees="true"/> <locator class="org.jboss.cache.buddyreplication.NextMemberBuddyLocator"> <properties> numBuddies = 1 ignoreColocatedBuddies = false </properties> </locator> </buddy> <jgroupsConfig> <TCP bind_port="2000" port_range="5" enable_bundling="false"/> <TCPPING initial_hosts="localhost[2000]" port_range="5" timeout="3000" num_initial_members="1" /> <FD_SOCK/> <FD timeout="10000" max_tries="5" shun="true"/> <VERIFY_SUSPECT timeout="15000"/> <pbcast.NAKACK max_xmit_size="60000" use_mcast_xmit="false" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800" discard_delivered_msgs="true"/> <UNICAST timeout="300,600,1200,2400,3600"/> <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000" max_bytes="400000"/> <pbcast.GMS print_local_addr="true" join_timeout="5000" join_retry_timeout="2000" shun="false" view_bundling="true" view_ack_collection_timeout="5000"/> <pbcast.STREAMING_STATE_TRANSFER/> <pbcast.FLUSH timeout="0"/> </jgroupsConfig> </clustering> </jbosscache> {code} Here are some logs: {code} 2009-07-30 16:15:25,914 [main] TRACE cache.interceptors.InvocationContextInterceptor - Invoked with command RemoveNodeCommand{fqn=/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null} and InvocationContext [InvocationContext{transaction=null, globalTransaction=null, transactionContext=null, optionOverrides=Option{failSilently=false, cacheModeLocal=false, dataVersion=null, suppressLocking=false, lockAcquisitionTimeout=-1, forceDataGravitation=false, skipDataGravitation=false, forceAsynchronous=false, forceSynchronous=false}, originLocal=true}] 2009-07-30 16:15:25,916 [main] TRACE cache.interceptors.InvocationContextInterceptor - Setting up transactional context. 2009-07-30 16:15:25,916 [main] TRACE cache.interceptors.InvocationContextInterceptor - Setting tx as null and gtx as null 2009-07-30 16:15:25,916 [main] TRACE cache.lock.MVCCLockManager - Attempting to lock /test/blah 2009-07-30 16:15:25,917 [main] TRACE commands.write.RemoveNodeCommand - perform(null, /test/blah) 2009-07-30 16:15:25,917 [main] TRACE commands.write.RemoveNodeCommand - node /test/blah not found 2009-07-30 16:15:25,917 [main] TRACE cache.interceptors.MVCCLockingInterceptor - Releasing lock on [/test/blah] for owner Thread[main,5,main] 2009-07-30 16:15:25,918 [main] TRACE cache.lock.MVCCLockManager - Attempting to unlock /test/blah 2009-07-30 16:15:25,918 [main] TRACE cache.interceptors.ReplicationInterceptor - invoking method RemoveNodeCommand, members=[127.0.0.1:2000, 127.0.0.1:2001], mode=REPL_SYNC, exclude_self=true, timeout=15000 2009-07-30 16:15:25,918 [main] TRACE cache.interceptors.ReplicationInterceptor - Broadcasting call RemoveNodeCommand{fqn=/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null} to recipient list null 2009-07-30 16:15:25,919 [main] TRACE cache.buddyreplication.BuddyManager - Transformed RemoveNodeCommand{fqn=/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null} to RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null} 2009-07-30 16:15:25,920 [main] TRACE cache.interceptors.ReplicationInterceptor - Setting call recipients to [127.0.0.1:2000] since the original list of recipients passed in is null. 2009-07-30 16:15:25,921 [main] TRACE jboss.cache.RPCManagerImpl - callRemoteMethods(): valid members are [127.0.0.1:2000] methods: ReplicateCommand{cmds=RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}} Using OOB? false 2009-07-30 16:15:25,921 [main] TRACE cache.marshall.CommandAwareRpcDispatcher - dests=[127.0.0.1:2000], command=ReplicateCommand{cmds=RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}}, mode=2, timeout=15000 2009-07-30 16:15:25,922 [main] TRACE cache.marshall.CacheMarshaller300 - Marshalling object ReplicateCommand{cmds=RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}} 2009-07-30 16:15:25,923 [main] TRACE cache.marshall.CommandAwareRpcDispatcher - real_dests=[127.0.0.1:2000] 2009-07-30 16:15:25,924 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.marshall.CacheMarshaller300 - Unmarshalled object ReplicateCommand{cmds=RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}} 2009-07-30 16:15:25,925 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.marshall.CommandAwareRpcDispatcher - Executing command: ReplicateCommand{cmds=RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}} [sender=127.0.0.1:2001] 2009-07-30 16:15:25,926 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.marshall.CommandAwareRpcDispatcher - This is a non-visitable command - so performing directly and not via the invoker. 2009-07-30 16:15:25,926 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.factories.ComponentRegistry - Testing if invocations are allowed. 2009-07-30 16:15:25,927 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE commands.remote.ReplicateCommand - Invoking command RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null}, with originLocal flag set to false. 2009-07-30 16:15:25,927 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.interceptors.InvocationContextInterceptor - Invoked with command RemoveNodeCommand{fqn=/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah, dataVersion=null, globalTransaction=null, skipSendingNodeEvents=false, parentFqn=null, targetNode=null} and InvocationContext [InvocationContext{transaction=null, globalTransaction=null, transactionContext=null, optionOverrides=Option{failSilently=false, cacheModeLocal=false, dataVersion=null, suppressLocking=false, lockAcquisitionTimeout=-1, forceDataGravitation=false, skipDataGravitation=false, forceAsynchronous=false, forceSynchronous=false}, originLocal=false}] 2009-07-30 16:15:25,929 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.interceptors.InvocationContextInterceptor - Setting up transactional context. 2009-07-30 16:15:25,929 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.interceptors.InvocationContextInterceptor - Setting tx as null and gtx as null 2009-07-30 16:15:25,929 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.lock.MVCCLockManager - Attempting to lock /_BUDDY_BACKUP_/127.0.0.1_2001/test/blah 2009-07-30 16:15:25,930 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE commands.write.RemoveNodeCommand - perform(null, /_BUDDY_BACKUP_/127.0.0.1_2001/test/blah) 2009-07-30 16:15:25,930 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE commands.write.RemoveNodeCommand - node /_BUDDY_BACKUP_/127.0.0.1_2001/test/blah not found 2009-07-30 16:15:25,930 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.interceptors.MVCCLockingInterceptor - Releasing lock on [/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah] for owner Thread[Incoming-1,TestDigitalVault,127.0.0.1:2000,5,Thread Pools] 2009-07-30 16:15:25,931 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.lock.MVCCLockManager - Attempting to unlock /_BUDDY_BACKUP_/127.0.0.1_2001/test/blah 2009-07-30 16:15:25,931 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.interceptors.InvocationContextInterceptor - Resetting invocation-scope options 2009-07-30 16:15:25,931 [Incoming-1,TestDigitalVault,127.0.0.1:2000] TRACE cache.marshall.CacheMarshaller300 - Marshalling object null 2009-07-30 16:15:25,932 [OOB-2,TestDigitalVault,127.0.0.1:2001] TRACE cache.marshall.CacheMarshaller300 - Unmarshalled object null 2009-07-30 16:15:25,933 [main] TRACE cache.marshall.CommandAwareRpcDispatcher - responses: [sender=127.0.0.1:2000, retval=null, received=true, suspected=false] 2009-07-30 16:15:25,933 [main] TRACE jboss.cache.RPCManagerImpl - (127.0.0.1:2001): responses for method ReplicateCommand: null 2009-07-30 16:15:25,934 [main] TRACE cache.interceptors.ReplicationInterceptor - responses=[] 2009-07-30 16:15:25,934 [main] TRACE cache.interceptors.InvocationContextInterceptor - Resetting invocation-scope options 2009-07-30 16:15:25,934 [main] TRACE cache.interceptors.InvocationContextInterceptor - Invoked with command GetNodeCommand{fqn=/test/blah} and InvocationContext [InvocationContext{transaction=null, globalTransaction=null, transactionContext=null, optionOverrides=Option{failSilently=false, cacheModeLocal=false, dataVersion=null, suppressLocking=false, lockAcquisitionTimeout=-1, forceDataGravitation=false, skipDataGravitation=false, forceAsynchronous=false, forceSynchronous=false}, originLocal=true}] 2009-07-30 16:15:25,935 [main] TRACE cache.interceptors.InvocationContextInterceptor - Setting up transactional context. 2009-07-30 16:15:25,936 [main] TRACE cache.interceptors.InvocationContextInterceptor - Setting tx as null and gtx as null 2009-07-30 16:15:25,937 [main] TRACE cache.mvcc.MVCCNodeHelper - Node /test/blah is not in context, fetching from container. 2009-07-30 16:15:25,937 [main] TRACE cache.interceptors.DataGravitatorInterceptor - Checking local existence of requested fqn /test/blah 2009-07-30 16:15:25,937 [main] TRACE cache.interceptors.DataGravitatorInterceptor - No need to gravitate; have this already. 2009-07-30 16:15:25,937 [main] TRACE cache.interceptors.CallInterceptor - Executing command: GetNodeCommand{fqn=/test/blah}. 2009-07-30 16:15:25,939 [main] TRACE commands.read.GetNodeCommand - Found node, returning UnversionedNode[ /test/blah data=[key]] 2009-07-30 16:15:25,939 [main] TRACE cache.interceptors.MVCCLockingInterceptor - Nothing to do since there are no modifications in scope. 2009-07-30 16:15:25,940 [main] TRACE cache.interceptors.InvocationContextInterceptor - Resetting invocation-scope options {code} As you can see first it's tried to delete "/test/blah" in the current instance and then "/_BUDDY_BACKUP_/127.0.0.1_2001/test/blah" in the other intsance .. both operations fail. -- 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

14 years, 8 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1517) Possibility of upgrading to JGroups 2.8 ?

by Galder Zamarreno (JIRA)

Possibility of upgrading to JGroups 2.8 ? ----------------------------------------- Key: JBCACHE-1517 URL: https://jira.jboss.org/jira/browse/JBCACHE-1517 Project: JBoss Cache Issue Type: Thirdparty Change Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 3.2.0.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Can we upgrade JBC 3.2 to use JGroups 2.8? Bela said JGroups 2.6 and 2.8 don't have on the wire compatibility, so if JBC 3.2 and JBC 3.1 clusters would not be able to cluster. org.jboss.cache.buddyreplication.NextMemberBuddyLocator is using IpAddress to figure out if candidate and data owner are in the same machine: // assume they're both IpAddresses?? InetAddress inetC = ((IpAddress) candidate).getIpAddress(); InetAddress inetD = ((IpAddress) dataOwner).getIpAddress(); There's also some test classes making use of IpAddress, i.e. CacheJmxWrapperTest and GlobalTransactionTest -- 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

14 years, 8 months

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1518) getChild() returning null

by Galder Zamarreno (JIRA)

getChild() returning null ------------------------- Key: JBCACHE-1518 URL: https://jira.jboss.org/jira/browse/JBCACHE-1518 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.1.0.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Running the following code from the user guide throws an NPE in line 3: 1. Map lotsOfData = generateData(); 2. cache.put("/a/b/c", lotsOfData); 3. cache.getRoot().getChild("/a").setResident(true); 4. cache.getRoot().getChild("/a/b").setResident(true); Needs further investigation... -- 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

14 years, 8 months

2
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1524) ClassCastException processing GravitateDataCommand results in LegacyDataGravitatorInterceptor

by Paul Ferraro (JIRA)

ClassCastException processing GravitateDataCommand results in LegacyDataGravitatorInterceptor --------------------------------------------------------------------------------------------- Key: JBCACHE-1524 URL: https://jira.jboss.org/jira/browse/JBCACHE-1524 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 3.1.0.GA Reporter: Paul Ferraro Assignee: Manik Surtani Priority: Critical While running web session replication soak tests, we ran into the following failure using synchronous buddy replication. The issue, I think, resides in the LegacyDataGravitatorInterceptor.ResponseValidityFilter, the purpose of which is unclear to me. It does not actually filter out invalid responses, since ResponseValidityFilter.isAcceptable(...) always returns true. Consequently, the response processing in LegacyDataGravitatorInterceptor.gravitateData(Fqn) throws an ClassCastException if a response is not a GravitateResult instance, which was the case in the trace below: 17:42:30,454 ERROR [org.apache.catalina.connector.CoyoteAdapter] (ajp-jawa03%2F10.34.32.155-8009-141) An exception or error occurred in the container during the request processing [JBoss] java.lang.ClassCastException: org.jboss.cache.marshall.RequestIgnoredResponse cannot be cast to org.jboss.cache.buddyreplication.GravitateResult [JBoss] at org.jboss.cache.interceptors.LegacyDataGravitatorInterceptor.gravitateData(LegacyDataGravitatorInterceptor.java:381) [JBoss] at org.jboss.cache.interceptors.LegacyDataGravitatorInterceptor.remoteBackupGet(LegacyDataGravitatorInterceptor.java:295) [JBoss] at org.jboss.cache.interceptors.LegacyDataGravitatorInterceptor.handleGetMethod(LegacyDataGravitatorInterceptor.java:223) [JBoss] at org.jboss.cache.interceptors.LegacyDataGravitatorInterceptor.visitGetDataMapCommand(LegacyDataGravitatorInterceptor.java:115) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.LegacyCacheLoaderInterceptor.visitGetDataMapCommand(LegacyCacheLoaderInterceptor.java:209) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) [JBoss] at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.handleGetDataMapCommand(PrePostProcessingCommandInterceptor.java:249) [JBoss] at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitGetDataMapCommand(PrePostProcessingCommandInterceptor.java:239) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:301) [JBoss] at org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:283) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116) [JBoss] at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178) [JBoss] at org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:130) [JBoss] at org.jboss.cache.commands.AbstractVisitor.visitGetDataMapCommand(AbstractVisitor.java:100) [JBoss] at org.jboss.cache.commands.read.GetDataMapCommand.acceptVisitor(GetDataMapCommand.java:66) [JBoss] at org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287) [JBoss] at org.jboss.cache.invocation.CacheInvocationDelegate.getData(CacheInvocationDelegate.java:570) [JBoss] at org.jboss.ha.cachemanager.CacheManagerManagedCache.getData(CacheManagerManagedCache.java:212) [JBoss] at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.JBossCacheWrapper.getData(JBossCacheWrapper.java:55) [JBoss] at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.getSessionData(AbstractJBossCacheService.java:348) [JBoss] at org.jboss.web.tomcat.service.session.JBossCacheManager.loadSession(JBossCacheManager.java:1854) [JBoss] at org.jboss.web.tomcat.service.session.JBossCacheManager.findSession(JBossCacheManager.java:491) [JBoss] at org.apache.catalina.connector.Request.doGetSession(Request.java:2320) [JBoss] at org.apache.catalina.connector.Request.getSession(Request.java:2094) [JBoss] at org.jboss.web.tomcat.service.session.JvmRouteValve.checkJvmRoute(JvmRouteValve.java:95) [JBoss] at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:85) [JBoss] at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62) [JBoss] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92) [JBoss] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126) [JBoss] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70) [JBoss] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) [JBoss] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [JBoss] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158) [JBoss] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [JBoss] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330) [JBoss] at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436) [JBoss] at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:384) [JBoss] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) [JBoss] at java.lang.Thread.run(Thread.java:619) -- 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

14 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1432) Cache corrupted by 64bit windows member

by Bill Middleton (JIRA)

Cache corrupted by 64bit windows member --------------------------------------- Key: JBCACHE-1432 URL: https://jira.jboss.org/jira/browse/JBCACHE-1432 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 2.2.1.CR1 Environment: Windows 64bit OS with either 32 or 64bit jvm in cluster with any linux OS (32 or 64bit) with any linux jvm. Reporter: Bill Middleton Assignee: Manik Surtani Fix For: 3.1.0 Hello. We've run into some trouble in attempting to bring a 64bit windows machine into an existing cluster. The cluster has (had) two 64bit linux members and was running fine when we attempted to insert a 64bit windows machine into the cluster. Anytime the 64bit windows machine wrote a node, the node was thereafter unreadable by either of the original cluster members. Exceptions of the following form were thrown by the other members (will attach stacktrace as comment) I attempted to get help on this issue in the user forum, but it seems that nobody else is running 64bit windows as a cluster member with other OS's in the cluster. I hope perhaps someone can at least confirm this now formally? -- 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

14 years, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1522) SimpleTest doesn't synchronize access to DescriptiveStatistics objects

by Adam Morrison (JIRA)

SimpleTest doesn't synchronize access to DescriptiveStatistics objects ---------------------------------------------------------------------- Key: JBCACHE-1522 URL: https://jira.jboss.org/jira/browse/JBCACHE-1522 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: CacheBenchFwk Environment: Multicore/SMP Reporter: Adam Morrison Assignee: Manik Surtani I was using SimpleTest in local mode. It creates several threads, all of which concurrently access the results' DescriptiveStatistics objects, but DescriptiveStatistics is not a thread safe object. -- 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

14 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1503) ClusteredCacheLoader does not work with MVCC

by Krzysztof Sobolewski (JIRA)

ClusteredCacheLoader does not work with MVCC -------------------------------------------- Key: JBCACHE-1503 URL: https://jira.jboss.org/jira/browse/JBCACHE-1503 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Clustering Affects Versions: 3.1.0.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani ClusteredCacheLoader does not seem to work with MVCC - if you take the test from the suite, ClusteredCacheLoaderTest, and remove/disable lines 75-76, thus switching from Pessimistic to MVCC, all tests fail (except those testing concurrency). I guess it should work that way? -- 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

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1520) Possible typo in MVCCTransactionContext and MVCCInvocationContext

by Krzysztof Sobolewski (JIRA)

Possible typo in MVCCTransactionContext and MVCCInvocationContext ----------------------------------------------------------------- Key: JBCACHE-1520 URL: https://jira.jboss.org/jira/browse/JBCACHE-1520 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.1.0.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani While investigating JBCACHE-1519 I spotted two lines that look very suspicious: === src/main/java/org/jboss/cache/transaction/MVCCTransactionContext.java ================================================================== --- src/main/java/org/jboss/cache/transaction/MVCCTransactionContext.java (revision 7145) +++ src/main/java/org/jboss/cache/transaction/MVCCTransactionContext.java (revision 7146) @@ -110,6 +110,6 @@ public void putLookedUpNodes(Map<Fqn, NodeSPI> lookedUpNodes) { - lookedUpNodes.putAll(lookedUpNodes); + this.lookedUpNodes.putAll(lookedUpNodes); } } === src/main/java/org/jboss/cache/invocation/MVCCInvocationContext.java ================================================================== --- src/main/java/org/jboss/cache/invocation/MVCCInvocationContext.java (revision 7145) +++ src/main/java/org/jboss/cache/invocation/MVCCInvocationContext.java (revision 7146) @@ -93,7 +93,7 @@ if (this.lookedUpNodes == null) this.lookedUpNodes = new HashMap<Fqn, NodeSPI>(lookedUpNodes); else - lookedUpNodes.putAll(lookedUpNodes); + this.lookedUpNodes.putAll(lookedUpNodes); } } These two lines are effectively a NOP, and that's why I think it's a typo, or at least something like that :) -- 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

14 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1504) Activation of a passivated node can remove parents from cache loader

by Krzysztof Sobolewski (JIRA)

Activation of a passivated node can remove parents from cache loader -------------------------------------------------------------------- Key: JBCACHE-1504 URL: https://jira.jboss.org/jira/browse/JBCACHE-1504 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders, Eviction Affects Versions: 3.1.0.CR1 Reporter: Krzysztof Sobolewski Assignee: Manik Surtani The test (attached) performs the following steps: 1a) put(/a/a/a, x, x) 1b) put(/a/a, x, x) 2) evict(/a, true) 3) put(/a/a/a, x, y) 3a) ActivationInterceptor removes /a/a/a from cache loader and parents (if also loaded) 4) test that get(/a/a, x) is not null fails The thing is that during step 3 the node (/a/a/a) gets loaded; this also needs to create its parent (/a/a) because it too was evicted. The parent is created empty (not loaded) but it has a flag DATA_LOADED set, so during the following step 3a its data gets removed too, because ActivationInterceptor thinks it's safe to do that. -- 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

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1476) TransactionLog generates spurious ERROR logs on read-only transactions

by Krzysztof Sobolewski (JIRA)

TransactionLog generates spurious ERROR logs on read-only transactions ---------------------------------------------------------------------- Key: JBCACHE-1476 URL: https://jira.jboss.org/jira/browse/JBCACHE-1476 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Transactions Affects Versions: 3.0.2.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani Attachments: TransactionLogTest.patch We're testing our internal component with JBoss Cache 3.x and we noticed lots of ERROR logs from TransactionLog like this one: 2009-02-11 13:47:49,773 ERROR [org.jboss.cache.transaction.TransactionLog] (main) Could not find matching prepare for commit: GlobalTransaction:<192.168.1.18:7900>:3 It turns out that these logs are harmless and happen only on transactions that are committed without doing any writes (i.e. read-only transactions). Even though it's mostly harmless, it's annoying, hence this bug. I'm going to attach a patch with a test case, which modifies the log4j configuration and adds a "deadly" appender to TransactionLog's logger to demonstrate the issue (it's a little bit funny...) -- 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

14 years, 9 months

3
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues July 2009