[JBoss JIRA] (ISPN-3916) Expiration reaper is not enabled until lifespan or max-idle is set
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3916?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3916:
--------------------------------
Labels: 630 (was: )
> Expiration reaper is not enabled until lifespan or max-idle is set
> ------------------------------------------------------------------
>
> Key: ISPN-3916
> URL: https://issues.jboss.org/browse/ISPN-3916
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 6.0.1.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> If a cache is added where entities are with and without expiration by external processes it is expected that the reaper purge the data from memory and datastore.
> As the reaper is only enabled for the cache if the element
> <expiration interval="millis" lifespan="millis" max-idle="millis"/>
> has one of the attributes lifespan or max-idle set to a value >0
> The expired entities will not be removed from the memory or datastore.
> This is an unexpected behaviour and might end in a memory bottleneck if a server is up for a long time.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (ISPN-3878) Unhandled failing ST cancel leads to deadlock
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3878?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3878:
--------------------------------
Labels: 630 (was: )
> Unhandled failing ST cancel leads to deadlock
> ---------------------------------------------
>
> Key: ISPN-3878
> URL: https://issues.jboss.org/browse/ISPN-3878
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 6.0.1.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> Two concurrent rebalances can lead to deadlock. Example situation when two rebalances can be executed in parallel is when the coordinator is leaving a cluster; it sends REBALANCE_START and passes away. Then, the new coordinator recovers cluster status and sends REBALANCE_START as well.
> 1. Node is requesting segments for the old topology, StateConsumerImpl.isTransferThreadRunning is set to true
> 2. Node waits for StateResponseCommand in SCI: InboundTransferTask.awaitCompletion()
> 3. New rebalance is started, changing the CH - requested segment is not in the new CH
> 4. Some ST are canceled, the cancel command is sent and taking a long time
> 5. StateReponseCommand is received, but in SCI.applyState it is found out that this segment is no longer owned so the task is not completed/cancelled
> 6. Later, we get TimeoutException from InboundTransferTask.sendCancelCommand, and no more cancellations are executed
> Result: the inbound transfer thread is stuck and rebalance is never completed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (ISPN-3880) HotRod Rolling Upgrades -- use HR protocol of version 1.2 for inter-server communication
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3880?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3880:
--------------------------------
Labels: 630 (was: )
> HotRod Rolling Upgrades -- use HR protocol of version 1.2 for inter-server communication
> -----------------------------------------------------------------------------------------
>
> Key: ISPN-3880
> URL: https://issues.jboss.org/browse/ISPN-3880
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Tomas Sykora
> Assignee: Tristan Tarrant
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> See linked bugzilla.
> This issue is for the scenario of "old" 5.2.4.Final cluster being migrated to 6.0.0 and this causes protocol mismatch error.
> Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:155)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_02]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_02]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_02]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_02]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> ... 18 more
> Caused by: org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): scala.MatchError: 13 (of class java.lang.Byte)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.PingOperation.execute(PingOperation.java:44)
> at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:30) at org.infinispan.client.hotrod.impl.operations.FaultTolerantPingOperation.executeOperation(FaultTolerantPingOperation.java:16) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:433)
> at org.infinispan.client.hotrod.RemoteCacheManager.ping(RemoteCacheManager.java:632)
> at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:613)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:524)
> at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:520)
> at org.infinispan.persistence.remote.RemoteStore.start(RemoteStore.java:89)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:122)
> ... 23 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (ISPN-3895) Compilation with Java 1.6.0_65 fails
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3895?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3895:
--------------------------------
Labels: 630 (was: )
> Compilation with Java 1.6.0_65 fails
> -------------------------------------
>
> Key: ISPN-3895
> URL: https://issues.jboss.org/browse/ISPN-3895
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.0.0.Final
> Reporter: Valerio Schiavoni
> Assignee: Tristan Tarrant
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> I'm trying to follow the 'Getting started with Infinispan' as published here:
> http://infinispan.org/docs/6.0.x/getting_started/getting_started.html
> There, it is specified: "A Java 6.0 JDK"
> Compiling INFINISPAN-7.0.0-SNAPSHOT with Maven 3.1.1 and java version "1.6.0_65, the maven-enforcer-plugin complains:
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce' with basic configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (s) project = MavenProject: org.infinispan:infinispan-parent:7.0.0-SNAPSHOT @ /Users/veleno/workspace-git/infinispan/parent/pom.xml
> [DEBUG] (s) version = [1.7,)
> [DEBUG] (s) version = [3.0.3,)
> [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireJavaVersion@15194a34, org.apache.maven.plugins.enforcer.RequireMavenVersion@2f56a6be]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@7b681460
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireJavaVersion
> [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireJavaVersion is cacheable.
> [DEBUG] Detected Java String: 1.6.0_65
> [DEBUG] Normalized Java String: 1.6.0-65
> [DEBUG] Parsed Version: Major: 1 Minor: 6 Incremental: 0 Build: 65 Qualifier: null
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Detected JDK Version: 1.6.0-65 is not in the allowed range [1.7,).
> at org.apache.maven.plugins.enforcer.AbstractVersionEnforcer.enforceVersion(AbstractVersionEnforcer.java:101)
> at org.apache.maven.plugins.enforcer.RequireJavaVersion.execute(RequireJavaVersion.java:65)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:186)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> 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.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> $java -version:
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (ISPN-3912) Wrong description for jboss-infinispan-core_5_2.xsd expiration element
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3912?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3912:
--------------------------------
Labels: 630 (was: )
> Wrong description for jboss-infinispan-core_5_2.xsd expiration element
> ----------------------------------------------------------------------
>
> Key: ISPN-3912
> URL: https://issues.jboss.org/browse/ISPN-3912
> Project: Infinispan
> Issue Type: Bug
> Components: Documentation-Core
> Reporter: Wolf-Dieter Fink
> Assignee: Mircea Markus
> Priority: Minor
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> The XSD contains a confusing description for expiration/interval.
> wakeUpInterval sould be interval!
> <xs:complexType name="expiration">
> ....
> <xs:attribute name="interval" type="xs:long" default="5000">
> <xs:annotation>
> <xs:documentation>Interval (in milliseconds) between subsequent runs to purge expired entries from memory and any cache stores. If you wish to disable the periodic eviction process altogether, set wakeupInterval to -1.</xs:documentation>
> </xs:annotation>
> </xs:attribute>
> </xs:complexType>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month
[JBoss JIRA] (ISPN-3873) Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3873?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3873:
--------------------------------
Labels: 630 (was: )
> Race condition in AbstractInvocationContextFactory (results in NullPointerException in EquivalentHashMap when receiving an invalidate command during startup)
> -------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3873
> URL: https://issues.jboss.org/browse/ISPN-3873
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 6.0.1.Final
> Environment: Ubuntu Linux 12.04_LTS, Oracle Java SE 1.7.0_45
> Reporter: Karl von Randow
> Assignee: Mircea Markus
> Labels: 630
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
> Attachments: infinispan.trace.gz
>
>
> Sometimes when I start one server in a cluster I see the NullPointerException reproduced below. This only occurs if there is another server running. I run multiple caches with clustering using invalidation. JGroups using JDBC_PING and TCP. The caches are non-transactional.
> The NPE is because the keyEq (Equivalence instance for keys) is null. I believe this is because the command is processed before the start() method has been called on the AbstractInvocationContextFactory, as the start() method sets the keyEq ivar.
> At this point I'm not sure how to fix it!
> java.lang.NullPointerException
> at org.infinispan.commons.equivalence.EquivalentHashMap.put(EquivalentHashMap.java:176)
> at org.infinispan.commons.equivalence.EquivalentHashSet.add(EquivalentHashSet.java:109)
> at org.infinispan.context.impl.NonTxInvocationContext.addLockedKey(NonTxInvocationContext.java:84)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.lock(LockManagerImpl.java:190)
> at org.infinispan.util.concurrent.locks.LockManagerImpl.acquireLockNoCheck(LockManagerImpl.java:181)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockKey(AbstractLockingInterceptor.java:149)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitInvalidateCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73)
> at org.infinispan.commands.AbstractVisitor.visitInvalidateCommand(AbstractVisitor.java:111)
> at org.infinispan.commands.write.InvalidateCommand.acceptVisitor(InvalidateCommand.java:118)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.commands.remote.BaseRpcInvokingCommand.processVisitableCommand(BaseRpcInvokingCommand.java:39)
> at org.infinispan.commands.remote.SingleRpcCommand.perform(SingleRpcCommand.java:48)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:95)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:186)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:84)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:259)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:211)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:247)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:665)
> at org.jgroups.JChannel.up(JChannel.java:730)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1019)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:182)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:434)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.stack.Protocol.up(Protocol.java:409)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294)
> at org.jgroups.protocols.RSVP.up(RSVP.java:221)
> at org.jgroups.protocols.UNICAST2.removeAndPassUp(UNICAST2.java:919)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:800)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:415)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:600)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:147)
> at org.jgroups.protocols.FD.up(FD.java:255)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:301)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:209)
> at org.jgroups.protocols.Discovery.up(Discovery.java:379)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1399)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1585)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 1 month