January 2010 - jbosscache-issues - Jboss List Archives

[JBoss JIRA] Created: (JBCACHE-1538) State transfer failures during semi-concurrent startup

by Brian Stansberry (JIRA)

State transfer failures during semi-concurrent startup ------------------------------------------------------ Key: JBCACHE-1538 URL: https://jira.jboss.org/jira/browse/JBCACHE-1538 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Clustering Affects Versions: 3.2.0.GA Reporter: Brian Stansberry Assignee: Manik Surtani Saw this twice today when starting 2 AS instances at roughly the same time, i.e. w/in 5 or so seconds: >From the node providing state: --------------------------------------------------------- GMS: address is 127.0.0.1:45892 (cluster=DefaultPartition-SessionCache) --------------------------------------------------------- 2009-08-27 22:03:57,397 INFO [org.jboss.cache.RPCManagerImpl] (main) Received new cluster view: [127.0.0.1:45892|0] [127.0.0.1:45892] 2009-08-27 22:03:57,896 INFO [org.jboss.cache.RPCManagerImpl] (Incoming-19,127.0.0.1:45892) Received new cluster view: [127.0.0.1:45892|1] [127.0.0.1:45892, 192.168.201.145:60963] 2009-08-27 22:03:58,210 INFO [org.jboss.cache.RPCManagerImpl] (Incoming-6,127.0.0.1:45892) Received new cluster view: [127.0.0.1:45892|1] [127.0.0.1:45892, 192.168.201.145:60963] 2009-08-27 22:03:59,767 INFO [org.jboss.cache.RPCManagerImpl] (Incoming-16,127.0.0.1:45892) Received new cluster view: [127.0.0.1:45892|1] [127.0.0.1:45892, 192.168.201.145:60963] 2009-08-27 22:04:00,965 INFO [org.jboss.cache.RPCManagerImpl] (Incoming-7,127.0.0.1:45892) Received new cluster view: [127.0.0.1:45892|1] [127.0.0.1:45892, 192.168.201.145:60963] 2009-08-27 22:04:00,978 ERROR [org.jboss.cache.remoting.jgroups.ChannelMessageListener] (Incoming-8,127.0.0.1:45892) Caught java.lang.NullPointerException while responding to state transfer request java.lang.NullPointerException at org.jboss.cache.statetransfer.LegacyStateTransferGenerator.generateNodeDataList(LegacyStateTransferGenerator.java:175) at org.jboss.cache.statetransfer.LegacyStateTransferGenerator.marshallTransientState(LegacyStateTransferGenerator.java:169) at org.jboss.cache.statetransfer.LegacyStateTransferGenerator.generateState(LegacyStateTransferGenerator.java:82) at org.jboss.cache.statetransfer.LegacyStateTransferManager.getState(LegacyStateTransferManager.java:83) at org.jboss.cache.remoting.jgroups.ChannelMessageListener.getState(ChannelMessageListener.java:163) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:658) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776) at org.jgroups.JChannel.up(JChannel.java:1338) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:462) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:486) at org.jgroups.protocols.pbcast.STATE_TRANSFER.requestApplicationStates(STATE_TRANSFER.java:241) at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateReq(STATE_TRANSFER.java:374) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:117) at org.jgroups.protocols.FRAG2.up(FRAG2.java:188) at org.jgroups.protocols.FC.up(FC.java:473) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:821) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:616) at org.jgroups.protocols.UNICAST.up(UNICAST.java:282) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:758) at org.jgroups.protocols.BARRIER.up(BARRIER.java:136) 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:309) 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$ProtocolAdapter.up(TP.java:2327) at org.jgroups.protocols.TP.passMessageUp(TP.java:1261) at org.jgroups.protocols.TP.access$100(TP.java:49) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1838) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1817) 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) 2009-08-27 22:04:00,991 INFO [org.jboss.cache.RPCManagerImpl] (main) Cache local address is 127.0.0.1:45892 2009-08-27 22:04:01,022 INFO [org.jboss.cache.RPCManagerImpl] (Incoming-11,127.0.0.1:45892) Received new cluster view: [127.0.0.1:45892|2] [127.0.0.1:45892] The node receiving the state doesn't deal with the failure cleanly: --------------------------------------------------------- GMS: address is 192.168.201.145:60963 (cluster=DefaultPartition-SessionCache) --------------------------------------------------------- 2009-08-27 22:04:00,968 INFO [org.jboss.cache.RPCManagerImpl] (main) Received new cluster view: [127.0.0.1:45892|1] [127.0.0.1:45892, 192.168.201.145:60963] 2009-08-27 22:04:00,981 INFO [org.jboss.cache.statetransfer.LegacyStateTransferIntegrator] (Incoming-7,192.168.201.145:60963) Using version 4096 2009-08-27 22:04:00,989 INFO [org.jboss.cache.RPCManagerImpl] (main) Cache local address is 192.168.201.145:60963 2009-08-27 22:04:00,989 INFO [org.jboss.cache.RPCManagerImpl] (main) Disconnecting and closing the Channel 2009-08-27 22:04:01,030 ERROR [org.jboss.web.tomcat.service.session.JBossCacheManager.Order] (main) Unable to start manager. org.jboss.cache.CacheException: java.lang.reflect.InvocationTargetException at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:148) at org.jboss.cache.factories.ComponentRegistry$PrioritizedMethod.invoke(ComponentRegistry.java:1012) at org.jboss.cache.factories.ComponentRegistry.internalStart(ComponentRegistry.java:778) at org.jboss.cache.factories.ComponentRegistry.start(ComponentRegistry.java:632) at org.jboss.cache.invocation.CacheInvocationDelegate.start(CacheInvocationDelegate.java:345) at org.jboss.ha.cachemanager.CacheManagerManagedCache.start(CacheManagerManagedCache.java:98) at org.jboss.web.tomcat.service.session.distributedcache.impl.jbc.AbstractJBossCacheService.start(AbstractJBossCacheService.java:206) at org.jboss.web.tomcat.service.session.JBossCacheManager.startEmbedded(JBossCacheManager.java:2584) at org.jboss.web.tomcat.service.session.JBossCacheManager.start(JBossCacheManager.java:789) at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:447) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tomcat.util.modeler.BaseModelMBean.setAttribute(BaseModelMBean.java:414) at org.jboss.mx.server.RawDynamicInvoker.setAttribute(RawDynamicInvoker.java:70) at org.jboss.mx.server.MBeanServerImpl.setAttribute(MBeanServerImpl.java:617) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeployInternal(TomcatDeployment.java:348) at org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy(TomcatDeployment.java:142) at org.jboss.web.deployers.AbstractWarDeployment.start(AbstractWarDeployment.java:461) at org.jboss.web.deployers.WebModule.startModule(WebModule.java:118) at org.jboss.web.deployers.WebModule.start(WebModule.java:97) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96) at org.jboss.mx.server.Invocation.invoke(Invocation.java:88) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668) at org.jboss.system.microcontainer.ServiceProxy.invoke(ServiceProxy.java:206) at $Proxy38.start(Unknown Source) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:42) at org.jboss.system.microcontainer.StartStopLifecycleAction.installAction(StartStopLifecycleAction.java:37) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.system.microcontainer.ServiceControllerContext.install(ServiceControllerContext.java:297) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.system.ServiceController.doChange(ServiceController.java:688) at org.jboss.system.ServiceController.start(ServiceController.java:460) at org.jboss.system.deployers.ServiceDeployer.start(ServiceDeployer.java:163) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:99) at org.jboss.system.deployers.ServiceDeployer.deploy(ServiceDeployer.java:46) at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1440) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1158) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1179) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1211) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1099) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:823) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:782) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70) at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53) at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:403) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1632) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:935) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1083) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:985) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:775) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.system.server.profileservice.repository.AbstractProfileService.registerProfile(AbstractProfileService.java:308) at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:256) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461) at org.jboss.Main.boot(Main.java:221) at org.jboss.Main$1.run(Main.java:556) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.jboss.cache.util.reflect.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:144) ... 84 more Caused by: org.jboss.cache.CacheException: Unable to fetch state on startup at org.jboss.cache.RPCManagerImpl.start(RPCManagerImpl.java:396) ... 89 more Caused by: org.jboss.cache.CacheException: java.lang.ClassCastException: org.jboss.cache.marshall.NodeDataExceptionMarker cannot be cast to java.util.List at org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateTransientState(LegacyStateTransferIntegrator.java:118) at org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateState(LegacyStateTransferIntegrator.java:88) at org.jboss.cache.statetransfer.LegacyStateTransferManager.setState(LegacyStateTransferManager.java:155) at org.jboss.cache.statetransfer.DefaultStateTransferManager.setState(DefaultStateTransferManager.java:163) at org.jboss.cache.remoting.jgroups.ChannelMessageListener.setState(ChannelMessageListener.java:190) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:676) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:776) at org.jgroups.JChannel.up(JChannel.java:1251) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:462) at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:486) at org.jgroups.protocols.pbcast.STATE_TRANSFER.handleStateRsp(STATE_TRANSFER.java:430) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:124) at org.jgroups.protocols.FRAG2.up(FRAG2.java:188) at org.jgroups.protocols.FC.up(FC.java:473) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:821) at org.jgroups.protocols.VIEW_SYNC.up(VIEW_SYNC.java:192) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233) at org.jgroups.protocols.UNICAST.handleDataReceived(UNICAST.java:616) at org.jgroups.protocols.UNICAST.up(UNICAST.java:282) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:758) at org.jgroups.protocols.BARRIER.up(BARRIER.java:136) 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:309) 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$ProtocolAdapter.up(TP.java:2327) at org.jgroups.protocols.TP.passMessageUp(TP.java:1261) at org.jgroups.protocols.TP.access$100(TP.java:49) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1838) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1817) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ... 1 more Caused by: java.lang.ClassCastException: org.jboss.cache.marshall.NodeDataExceptionMarker cannot be cast to java.util.List at org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.readNodesAsList(LegacyStateTransferIntegrator.java:278) at org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateTransientState(LegacyStateTransferIntegrator.java:217) at org.jboss.cache.statetransfer.LegacyStateTransferIntegrator.integrateTransientState(LegacyStateTransferIntegrator.java:105) ... 34 more -- 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

16 years, 2 months

4
8
0 / 0

[JBoss JIRA] Created: (JBCACHE-1566) Bad performance when bigger objects are used

by tbech (JIRA)

Bad performance when bigger objects are used -------------------------------------------- Key: JBCACHE-1566 URL: https://jira.jboss.org/jira/browse/JBCACHE-1566 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: tbech Assignee: Manik Surtani Attachments: SimpleTest.java I've used benchmark framework to test jbosscache with various sizes of the objects in the case. Suprisingly in my tests, there was degradation of performance for bigger objects. I've modifed StringTest.java in the way, that is PUT into cache random strings (with defined size). For 50 character strings, cache performed 1800 PUTs/s for 4 nodes. But for 500 character strings, it was 750 and 2000 character strings it was just 50. In localMode (one-node), it run the same undepending on the string size. I've double checked configuration, network, multicast - it looks ok. (I've applied http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/5...., but it didn't change anything). I've noticed one more strange behaviour: the random string I've generated with the function: return RandomStringUtils.random(2000, true, true); (RandomStringUtils comes from jakarta commons). It generates strings consisting of standard characters and digits. However when the generated string consists of all unicode characters return RandomStringUtils.random(500, true, true); and the size was 500, the performance of the test was similar as 2000 standard characters string. Is it some problem with serialization of objects? (As far as I remember in JBoss you use custom serializer). I've repeated those tests with Ehcache 1.7.2 and there was no significant drop of performance for 50/2000 chars strings. I attach modified SimpleTest.java. -- 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

16 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1568) org.jboss.cache.lock.TimeoutException reports lock is unlocked

by Dennis Reed (JIRA)

org.jboss.cache.lock.TimeoutException reports lock is unlocked -------------------------------------------------------------- Key: JBCACHE-1568 URL: https://jira.jboss.org/jira/browse/JBCACHE-1568 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 1.4.1.SP13 Reporter: Dennis Reed Assignee: Manik Surtani Priority: Minor During an INVALIDATION_SYNC cluster call, the following exception is reported. There is a lock TimeoutException, but it reports that the lock is not locked. This appears to be a race condition between the time the lock is checked and when the log is printed. [WARN ] [org.jboss.cache.TreeCache] replication failure with method_call _evict; id:8; Args: ( arg[0] = /path/to/data) exception org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/path/to/data, caller=Thread[IncomingMessageHandler (channel= CustomCache),5,JGroups threads], lock=<unlocked> (org.jboss.cache.lock.LockStrategyReadCommitted@7c72d14f) at org.jboss.cache.Node.acquire(Node.java:533) at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410) at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322) at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:196) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.InvalidationInterceptor.invoke(InvalidationInterceptor.java:60) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.TxInterceptor.handleNonTxMethod(TxInterceptor.java:379) at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:174) at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68) at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:179) at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5934) at org.jboss.cache.TreeCache._replicate(TreeCache.java:5211) at sun.reflect.GeneratedMethodAccessor228.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330) at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281) at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654) at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544) at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:779) at org.jgroups.JChannel.up(JChannel.java:1090) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382) at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:763) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.protocols.pbcast.GMS.receiveUpEvent(GMS.java:783) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:262) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:685) at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:517) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:170) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FD.up(FD.java:300) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.MERGE2.up(MERGE2.java:162) at org.jgroups.stack.Protocol.receiveUpEvent(Protocol.java:470) at org.jgroups.stack.Protocol.passUp(Protocol.java:520) at org.jgroups.protocols.TP.access$900(TP.java:47) at org.jgroups.protocols.TP$IncomingMessageHandler.run(TP.java:1343) at java.lang.Thread.run(Thread.java:595) Caused by: org.jboss.cache.lock.TimeoutException: read lock for /path/to/data could not be acquired by Thread[IncomingMessageHandler (channel=CustomCache),5,JGroups threads] after 0 ms. Locks: Read lock owners: [] Write lock owner: null , lock info: <unlocked> (org.jboss.cache.lock.LockStrategyReadCommitted@7c72d14f) at org.jboss.cache.lock.IdentityLock.acquireReadLock(IdentityLock.java:262) at org.jboss.cache.Node.acquireReadLock(Node.java:545) at org.jboss.cache.Node.acquire(Node.java:507) ... 60 more -- 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

16 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1555) Mvcc node peek could contain stale data

by Galder Zamarreno (JIRA)

Mvcc node peek could contain stale data --------------------------------------- Key: JBCACHE-1555 URL: https://jira.jboss.org/jira/browse/JBCACHE-1555 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Locking Affects Versions: 3.2.1.GA Reporter: Galder Zamarreno Assignee: Manik Surtani Fix For: 3.3.0.GA I've added some extra logging to the attached test case to find out where the problem is: 2009-11-06 19:37:52,762 1064 DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-1:) Peek internal node for fqn /foo/mynode 2009-11-06 19:37:52,763 1065 DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-1:) Peek returned UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3 2009-11-06 19:37:52,763 1065 TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-1:) Attempting to lock /foo/mynode ... 2009-11-06 19:37:52,763 1065 TRACE [org.jboss.cache.commands.write.PutKeyValueCommand] (pool-1-thread-1:) Perform('GlobalTransaction:<null>:3', '/foo/mynode', k='_lockthisplease_', v='_lockthisplease_') ... 2009-11-06 19:37:52,767 1069 DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-5:) Peek internal node for fqn /foo/mynode 2009-11-06 19:37:52,767 1069 DEBUG [org.jboss.cache.mvcc.MVCCNodeHelper] (pool-1-thread-5:) Peek returned UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3 2009-11-06 19:37:52,767 1069 TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-5:) Attempting to lock /foo/mynode ... 2009-11-06 19:37:52,774 1076 TRACE [org.jboss.cache.lock.MVCCLockManager] (pool-1-thread-1:) Attempting to unlock /foo/mynode ... 2009-11-06 19:37:52,777 1079 DEBUG [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) underlyingNode is UnversionedNode[ /foo/mynode data=[scalar, _lockthisplease_]]@fa39d7 2009-11-06 19:37:52,777 1079 DEBUG [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) node is UnversionedNode[ /foo/mynode data=[scalar]]@14e45b3 2009-11-06 19:37:52,778 1080 WARN [org.jboss.cache.mvcc.RepeatableReadNode] (pool-1-thread-5:) Detected write skew on Fqn [/foo/mynode]. Another process has changed the node since we last read it!. Unable to copy node for update. pool-1-thread-5 has peeked too early! it was waiting for lock that pool-1-thread-1 one and carried with old data. In the mean time, pool-1-thread-1 wrote the data and unlocked which allowed pool-1-thread-5 to continue but it had cached data that is now stale. -- 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

16 years, 3 months

2
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-1561) Issue on view change with single cache store

by Mircea Markus (JIRA)

Issue on view change with single cache store -------------------------------------------- Key: JBCACHE-1561 URL: https://jira.jboss.org/jira/browse/JBCACHE-1561 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mircea Markus Assignee: Manik Surtani -- 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

16 years, 3 months

3
4
0 / 0

[JBoss JIRA] Created: (JBCACHE-1564) Using asynchronous API of JGroups for asynchronous replication

by Krzysztof Sobolewski (JIRA)

Using asynchronous API of JGroups for asynchronous replication -------------------------------------------------------------- Key: JBCACHE-1564 URL: https://jira.jboss.org/jira/browse/JBCACHE-1564 Project: JBoss Cache Issue Type: Patch Security Level: Public (Everyone can see) Components: Replication Affects Versions: 3.2.1.GA Reporter: Krzysztof Sobolewski Assignee: Manik Surtani As I mentioned on Infinispan list, I run into some problems with NBST and asynchronous replication. Quoting my message: *** The thing is that the "asynchronous" replication uses the usual method of submitting a task to an Executor. This is no problem without NBST, because the tasks are not interested in responses and finish immediately, but with NBSP they need responses to facilitate replay. And since they need to wait for responses, they clog the Executor's threads and under sufficiently heavy load, it all degrades to effectively synchronous replication. And it happens quite fast, really. *** The fix in the attached patch creates a new class, AsynchronousRpcDispatcher, and makes CommandAwareRpcDispatcher extend it. The new class adds a new variant of castMessage() method - castMessageAsync(). I takes a ScheduledExecutorService where it schedules a timeout task, and a "closure" callback object, an implementation of AsyncCallback interface, which is invoked when the replication task is complete. "Completion" also means a timeout, in which case the callback is invoked with whatever responses were received. One thing I had to do was to "hack" the GroupRequest class from JGroups to expose responsesComplete() method. I just copied it and did the necessary modification, diff of which is also attached. The method I needed is used to check whether the received responses are enough to complete the request. There are also some minor stylistic tweaks in the patch unrelated to the real thing. -- 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

16 years, 3 months

3
5
0 / 0

[JBoss JIRA] Created: (JBCACHE-1557) EvictionTimer thread going into endless loop when using LFUAlgorithm

by Guenther Demetz (JIRA)

EvictionTimer thread going into endless loop when using LFUAlgorithm -------------------------------------------------------------------- Key: JBCACHE-1557 URL: https://jira.jboss.org/jira/browse/JBCACHE-1557 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Eviction Affects Versions: 3.2.1.GA Environment: Hibernate3.3.2GA using JBOSSCACHE3.2.1GA as second level cache implementation Database: SQLServer2008 Reporter: Guenther Demetz Assignee: Manik Surtani Background:Im using JBoss-cache 3.2.1 GA as 2L-cache for a Hibernate application. As Hibernate documentation does not suggest LRU as algorithm for 2L-cache, I use the LFU algorithm. At a certain point BaseEvictionAlgorithm#prune method never exits his loop anymore because of evictionQueue.getFirstNodeEntry() always returning the same value. Debugging the code we saw that the actual bug stays in method LFUQueue#removeNodeEntry (see code below) : This method don't handles correctly the case of non-existance of the node in the nodeMap: if ne == null, then neither removalQueue nor the evictionList is touched. This causes evictionQueue.getFirstNodeEntry() returning always the same result. Code: BaseEvictionAlgorithm.java ... protected void prune() throws EvictionException { NodeEntry entry; while ((entry = evictionQueue.getFirstNodeEntry()) != null) --> ENDLESS-LOOP because evict doesn't alter the evictionQueye { if (this.shouldEvictNode(entry)) { this.evict(entry); } else { break; } } } Code: LFUQueue.java: public void removeNodeEntry(NodeEntry entry) { NodeEntry ne = nodeMap.remove(entry.getFqn()); if (ne != null) { // don't remove directly from the LinkedList otherwise we will incur a O(n) = n // performance penalty for every removal! In the prune method for LFU, we will iterate the LinkedList through ONCE // doing a single O(n) = n operation and removal. This is much preferred over running O(n) = n every single time // remove is called. There is also special logic in the getFirstNodeEntry that will know to check // the removalQueue before returning. this.removalQueue.add(ne); /* if(!evictionList.remove(ne)) { throw new RuntimeException(""); } */ this.numElements -= ne.getNumberOfElements(); } } Solution: following Else-block added in method LFUQueue#removeNodeEntry resolves the problem. Code: else { // ELSE BLOCK: bugfix: this prevents endless loop in BaseEvictionAlgorithm#prune method if(!evictionList.remove(entry)) throw new RuntimeException(""); this.removalQueue.add(entry); this.numElements -= entry.getNumberOfElements(); } N.B.: In other parts of the code, i.e BaseEvictionAlgorithm: line 406 the non-existance of the node is properly handled, see following logging outputs: 13:55:11,712 DEBUG BaseEvictionAlgorithm:384 - Removing node /com/wuerth/phoenix/Cis/bc/persistent/jpa/ConcreteAccountPeer/assAccount/COLL/com.wuerth.phoenix.Cis.bc.persistent.jpa.ConcreteAccountPeer.assAccount#32770 from eviction queue and attempting eviction 13:55:11,712 DEBUG BaseEvictionAlgorithm:406 - processRemoveNodes(): Can't find node associated with fqn: /com/wuerth/phoenix/Cis/bc/persistent/jpa/ConcreteAccountPeer/assAccount/COLL/com.wuerth.phoenix.Cis.bc.persistent.jpa.ConcreteAccountPeer.assAccount#32770Could have been evicted earlier. Will just continue. regards G.D. -- 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

16 years, 3 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosscache-issues January 2010