August 2009 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1521) Docu: Remove AS integration sections and point to AS Clustering Guide

by Galder Zamarreno (JIRA)

Docu: Remove AS integration sections and point to AS Clustering Guide --------------------------------------------------------------------- Key: JBCACHE-1521 URL: https://jira.jboss.org/jira/browse/JBCACHE-1521 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.2.0.GA Sectiosn 5.2 and 5.3 in JBoss Cache's documentation should go away or simply refer/link to AS Clustering Guide, since AS Clustering knows how to do this best and the JBC docu, unless kept tightly in check, will always be outdated.: http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... http://www.jboss.org/file-access/default/members/jbosscache/freezone/docs... -- 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
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1529) Spurious ERROR logging from LegacyDataGravitatorInterceptor

by Brian Stansberry (JIRA)

Spurious ERROR logging from LegacyDataGravitatorInterceptor ----------------------------------------------------------- Key: JBCACHE-1529 URL: https://jira.jboss.org/jira/browse/JBCACHE-1529 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 3.1.0.GA Reporter: Brian Stansberry Assignee: Brian Stansberry Priority: Minor Fix For: 3.2.0.GA LegacyDataGravitatorInterceptor's analysis of gravitation results ignores the possibility of a RequestIgnoredResponse and logs a spurious ERROR msg if one is present: 19:33:39,381 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa02%2F10.34.32.154-8009-22) responses: [sender=10.34.32.155:55087, retval=GravitateResult dataFound=false nodeData=null fqn=null, received=true, suspected=false] [sender=10.34.32.156:46610, retval=org.jboss.cache.marshall.RequestIgnoredResponse@11b35365, received=true, suspected=false] [sender=10.34.32.153:15918, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/Jfca39I-AJ35UJL188b5wQ__, attrs={0=280, 1=1249493617228, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@53786e77, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.156_46610/JSESSION/st_localhost/Jfca39I-AJ35UJL188b5wQ__, received=true, suspected=false] 19:33:39,381 ERROR [org.jboss.cache.interceptors.LegacyDataGravitatorInterceptor] (ajp-jawa02%2F10.34.32.154-8009-22) Unexpected null response to call GravitateDataCommand{fqn=/JSESSION/st_localhost/Jfca39I-AJ35UJL188b5wQ__, searchSubtrees=true}. Simple to fix. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1528) Data gravitation prefers exception response over valid gravitation

by Brian Stansberry (JIRA)

Data gravitation prefers exception response over valid gravitation ------------------------------------------------------------------ Key: JBCACHE-1528 URL: https://jira.jboss.org/jira/browse/JBCACHE-1528 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Buddy Replication Affects Versions: 3.1.0.GA Reporter: Brian Stansberry Assignee: Manik Surtani A web request that performed a data gravitation for the session failed because one node returned an ISE while another returned the data. The ISE should have been ignored and the returned data used. The first log message below shows what was returned from the gravitation RPC; the second indicates that the ISE propagated. [JBoss] 16:48:56,696 TRACE [org.jboss.cache.marshall.CommandAwareRpcDispatcher] (ajp-jawa04%2F10.34.32.156-8009-7) responses: [sender=10.34.32.154:59373, retval=GravitateResult dataFound=false nodeData=null fqn=null, received=true, suspected=false] [JBoss] [sender=10.34.32.153:40508, retval=GravitateResult dataFound=true nodeData=[NodeData {fqn: /JSESSION/st_localhost/BrvolmfTMDqZAzEL1quXCA__, attrs={0=192, 1=1249483734634, 2=org.jboss.web.tomcat.service.session.distributedcache.spi.DistributableSessionMetadata@500942cd, 3=org.jboss.ha.framework.server.SimpleCachableMarshalledValue{raw=nullserialized=true}}}] fqn=/_BUDDY_BACKUP_/10.34.32.155_47742/JSESSION/st_localhost/BrvolmfTMDqZAzEL1quXCA__, received=true, suspected=false] [JBoss] [sender=10.34.32.155:47742, retval=java.lang.IllegalStateException: Cache not in STARTED state!, received=true, suspected=false] [JBoss] [JBoss] 16:48:56,698 ERROR [org.apache.catalina.connector.CoyoteAdapter] (ajp-jawa04%2F10.34.32.156-8009-7) An exception or error occurred in the container during the request processing [JBoss] java.lang.IllegalStateException: Cache not in STARTED state! [JBoss] at org.jboss.cache.invocation.CacheInvocationDelegate.cacheStatusCheck(CacheInvocationDelegate.java:695) [JBoss] at org.jboss.cache.invocation.CacheInvocationDelegate.getChildrenNamesInternal(CacheInvocationDelegate.java:652) [JBoss] at org.jboss.cache.invocation.CacheInvocationDelegate.getChildrenNames(CacheInvocationDelegate.java:639) [JBoss] at org.jboss.cache.commands.read.GravitateDataCommand.perform(GravitateDataCommand.java:130) .... The stack trace below is what was returned from the remote node; it's not the caller-side stack. -- 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
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1527) LockParentForChildInsertRemove ignored with PessimisticLocking

by Brian Stansberry (JIRA)

LockParentForChildInsertRemove ignored with PessimisticLocking -------------------------------------------------------------- Key: JBCACHE-1527 URL: https://jira.jboss.org/jira/browse/JBCACHE-1527 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.1.0.GA Reporter: Brian Stansberry Assignee: Manik Surtani >From looking at the JBC 3 code, it seems the LockParentForChildInsertRemove configuration is no longer respected for pessimistic locking. I can't trace any path from the property in Configuration to code that uses it. PessimisticLockInterceptor.handlePutCommand, handleMoveCommand and handleRemoveNodeCommand all always tell the lock manager to lock parents. handleEvictFqnCommand always tells the lock manager not to lock parents. This is causing failures in buddy replication testing when nodes join/leave clusters under load. There's a lot of data gravitation plus stuff like migrating defunct backup trees to "DEAD" regions. Too much contention for parent level locks. Plus locking on the structural parent to add/remove session nodes will suck for the session caching use case. -- 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-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, 9 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, 9 months

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-1526) GlobalTransaction lost upon buddy fqn transformation of RollbackCommand

by Paul Ferraro (JIRA)

GlobalTransaction lost upon buddy fqn transformation of RollbackCommand ----------------------------------------------------------------------- Key: JBCACHE-1526 URL: https://jira.jboss.org/jira/browse/JBCACHE-1526 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 During EAP5 web session buddy replication testing, the following trace logs caught my attention: [JBoss] 19:54:53,957 TRACE [org.jboss.cache.buddyreplication.BuddyManager] (ajp-jawa01%2F10.34.32.153-8009-979) Transformed RollbackCommand{gtx=GlobalTransaction:<10.34.32.153:54191>:1331} to RollbackCommand{gtx=null} [JBoss] 19:54:54,073 TRACE [org.jboss.cache.buddyreplication.BuddyManager] (ajp-jawa01%2F10.34.32.153-8009-981) Transformed RollbackCommand{gtx=GlobalTransaction:<10.34.32.153:54191>:1333} to RollbackCommand{gtx=null} [JBoss] 19:54:54,073 TRACE [org.jboss.cache.buddyreplication.BuddyManager] (ajp-jawa01%2F10.34.32.153-8009-981) Transformed RollbackCommand{gtx=GlobalTransaction:<10.34.32.153:54191>:1333} to RollbackCommand{gtx=null} This seems due to the following method in Fqn2BuddyFqnVisitor: public Object visitRollbackCommand(InvocationContext ctx, RollbackCommand command) throws Throwable { return factory.buildRollbackCommand(null); } Shouldn't we be propagating the GlobalTransaction as done in visitCommitCommand(...) and visitPrepareCommand(...)? -- 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-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, 9 months

2
7
0 / 0

[JBoss JIRA] Resolved: (JBCACHE-1340) Eager deadlock detection with 2 phase commits

by Manik Surtani (JIRA)

[ https://jira.jboss.org/jira/browse/JBCACHE-1340?page=com.atlassian.jira.p... ] Manik Surtani resolved JBCACHE-1340. ------------------------------------ Fix Version/s: (was: 3.3.0.GA) Resolution: Won't Fix > Eager deadlock detection with 2 phase commits > --------------------------------------------- > > Key: JBCACHE-1340 > URL: https://jira.jboss.org/jira/browse/JBCACHE-1340 > Project: JBoss Cache > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mircea Markus > Assignee: Manik Surtani > > as described in the forum -- 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

1
0
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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues August 2009