[JBoss JIRA] (ISPN-8784) CNFE with jdk10
by Olivier Lamy (JIRA)
[ https://issues.jboss.org/browse/ISPN-8784?page=com.atlassian.jira.plugin.... ]
Olivier Lamy commented on ISPN-8784:
------------------------------------
why is this issue marked as resolved?
I guess there is more todo than only upgrading surefire
org.apache.karaf.tooling:karaf-maven-plugin:4.2.0.M2:verify is failing as well.
> CNFE with jdk10
> ---------------
>
> Key: ISPN-8784
> URL: https://issues.jboss.org/browse/ISPN-8784
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Affects Versions: 9.2.0.CR2
> Environment: jdk10 (jvm 10-ea+42) (linux, osx)
> Reporter: Olivier Lamy
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 9.2.1.Final
>
>
> Trying to infinispan-core with jdk10 (jetty infinispan session manager) I get the following CNFE:
> {code}
> org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: Could not initialize class org.infinispan.commons.marshall.jboss.ExtendedRiverMarshaller
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.rethrowException(InvocationContextInterceptor.java:144)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.access$000(InvocationContextInterceptor.java:44)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor$1.apply(InvocationContextInterceptor.java:61)
> at org.infinispan.interceptors.InvocationExceptionFunction.apply(InvocationExceptionFunction.java:21)
> at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
> at org.infinispan.interceptors.InvocationStage.andExceptionally(InvocationStage.java:34)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:132)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:97)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1651)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1299)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1765)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:280)
> at org.infinispan.cache.impl.AbstractDelegatingCache.put(AbstractDelegatingCache.java:358)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:655)
> at org.eclipse.jetty.session.infinispan.InfinispanSessionDataStore.doStore(InfinispanSessionDataStore.java:216)
> at org.eclipse.jetty.server.session.AbstractSessionDataStore.store(AbstractSessionDataStore.java:103)
> at org.eclipse.jetty.server.session.DefaultSessionCache.shutdown(DefaultSessionCache.java:162)
> at org.eclipse.jetty.server.session.SessionHandler.shutdownSessions(SessionHandler.java:994)
> at org.eclipse.jetty.server.session.SessionHandler.doStop(SessionHandler.java:514)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:149)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:170)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:124)
> at org.eclipse.jetty.server.handler.ContextHandler.stopContext(ContextHandler.java:863)
> at org.eclipse.jetty.servlet.ServletContextHandler.stopContext(ServletContextHandler.java:381)
> at org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:927)
> at org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:297)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:149)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:170)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:124)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.stop(ContainerLifeCycle.java:149)
> at org.eclipse.jetty.util.component.ContainerLifeCycle.doStop(ContainerLifeCycle.java:170)
> at org.eclipse.jetty.server.handler.AbstractHandler.doStop(AbstractHandler.java:124)
> at org.eclipse.jetty.server.Server.doStop(Server.java:490)
> at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:89)
> at org.eclipse.jetty.server.session.TestServer.stop(TestServer.java:128)
> at org.eclipse.jetty.server.session.AbstractClusteredSessionScavengingTest.testNoScavenging(AbstractClusteredSessionScavengingTest.java:146)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> Caused by: java.lang.NoClassDefFoundError: Could not initialize class org.infinispan.commons.marshall.jboss.ExtendedRiverMarshaller
> at org.infinispan.commons.marshall.jboss.JBossMarshallerFactory.createMarshaller(JBossMarshallerFactory.java:49)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller$PerThreadInstanceHolder.getMarshaller(AbstractJBossMarshaller.java:314)
> at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.startObjectOutput(AbstractJBossMarshaller.java:90)
> at org.infinispan.marshall.core.ExternalJBossMarshaller.objectToObjectStream(ExternalJBossMarshaller.java:32)
> at org.infinispan.marshall.core.GlobalMarshaller.writeRawUnknown(GlobalMarshaller.java:603)
> at org.infinispan.marshall.core.GlobalMarshaller.writeUnknown(GlobalMarshaller.java:598)
> at org.infinispan.marshall.core.GlobalMarshaller.writeNonNullableObject(GlobalMarshaller.java:412)
> at org.infinispan.marshall.core.GlobalMarshaller.writeNullableObject(GlobalMarshaller.java:355)
> at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:188)
> at org.infinispan.marshall.core.GlobalMarshaller.writeObjectOutput(GlobalMarshaller.java:181)
> at org.infinispan.marshall.core.GlobalMarshaller.objectToBuffer(GlobalMarshaller.java:305)
> at org.infinispan.marshall.core.MarshalledEntryImpl.marshall(MarshalledEntryImpl.java:117)
> at org.infinispan.marshall.core.MarshalledEntryImpl.getValueBytes(MarshalledEntryImpl.java:100)
> at org.infinispan.persistence.file.SingleFileStore.write(SingleFileStore.java:322)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$writeToAllNonTxStores$9(PersistenceManagerImpl.java:529)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1492)
> at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllNonTxStores(PersistenceManagerImpl.java:529)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.storeEntry(CacheWriterInterceptor.java:452)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.lambda$visitPutKeyValueCommand$1(CacheWriterInterceptor.java:187)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:109)
> at org.infinispan.interceptors.impl.CacheWriterInterceptor.visitPutKeyValueCommand(CacheWriterInterceptor.java:179)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:201)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:128)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:102)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.setSkipRemoteGetsAndInvokeNextForDataCommand(EntryWrappingInterceptor.java:664)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitPutKeyValueCommand(EntryWrappingInterceptor.java:311)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:154)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitNonTxDataWriteCommand(AbstractLockingInterceptor.java:135)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataWriteCommand(NonTransactionalLockingInterceptor.java:38)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitPutKeyValueCommand(AbstractLockingInterceptor.java:85)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.updateStoreStatistics(CacheMgmtInterceptor.java:197)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitPutKeyValueCommand(CacheMgmtInterceptor.java:162)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:67)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
> ... 59 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8719) Error "ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server" when using remoteCache version 9 against infinispan-server version 8
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/ISPN-8719?page=com.atlassian.jira.plugin.... ]
Marek Posolda commented on ISPN-8719:
-------------------------------------
Thanks for the explanation. So if client version 9, doesn't work with infinispan server 8, this JIRA may be indeed closed.
I was probably expecting that this is supposed to work based on the configuration property PROTOCOL_VERSION defined on class org.infinispan.client.hotrod.impl.ConfigurationProperties. I assume that this property is useful if client wants to downgrade HotRod protocol version, as default value is always the newest version. And I assume that downgrading version is needed just if client wants to talk with older server.
> Error "ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server" when using remoteCache version 9 against infinispan-server version 8
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8719
> URL: https://issues.jboss.org/browse/ISPN-8719
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.2.0.CR1
> Reporter: Marek Posolda
> Assignee: Gustavo Fernandes
> Attachments: InfinispanRemote.java
>
>
> Steps to reproduce:
> 1) Use infinispan server version 8.2.6 (or JDG server 7.1.0) and start it.
> {code}
> cd JDG_HOME/bin
> ./standalone.sh
> {code}
> 2) Create sample java project having dependency on latest dependency 9.2.0.CR1 in pom.xml:
> {code}
> <dependencies>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-core</artifactId>
> <version>9.2.0.CR1</version>
> </dependency>
> <dependency>
> <groupId>org.infinispan</groupId>
> <artifactId>infinispan-cachestore-remote</artifactId>
> <version>9.2.0.CR1</version>
> </dependency>
> </dependencies>
> {code}
> 3) Add one simple java class based on the tutorial: http://infinispan.org/tutorials/simple/remote/ . The only difference is that I use hotRod protocolVersion 2.5 and calling:
> {code}
> remoteCache.keySet().iterator().hasNext()
> {code}. I am attaching the class in attachement.
> 4) Run the class. Seeing exception in both server log and on client-side.
> Server exception
> {code}
> 10:44:20,365 ERROR [org.infinispan.server.hotrod.CacheDecodeContext] (HotRodServerWorker-6-1) ISPN005003: Exception reported: java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server
> at org.infinispan.server.hotrod.iteration.DefaultIterationManager.getFactory(DefaultIterationManager.java:148)
> at org.infinispan.server.hotrod.iteration.DefaultIterationManager.start(DefaultIterationManager.java:131)
> at org.infinispan.server.hotrod.ContextHandler.realRead(ContextHandler.java:175)
> at org.infinispan.server.hotrod.ContextHandler.lambda$channelRead0$1(ContextHandler.java:57)
> at org.infinispan.server.hotrod.ContextHandler$$Lambda$86/1492247987.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Client exception:
> {code}
> Jan 24, 2018 10:44:20 AM org.infinispan.client.hotrod.impl.protocol.Codec20 checkForErrorsInResponseStatus
> WARN: ISPN004005: Error received from the server: java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server
> Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=5 returned server error (status=0x85): java.lang.IllegalStateException: ISPN006016: Factory 'org.infinispan.server.hotrod.HotRodServer$ToEmptyBytesKeyValueFilterConverter' not found in server
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:408)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:162)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:148)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:60)
> at org.infinispan.client.hotrod.impl.operations.IterationStartOperation.executeOperation(IterationStartOperation.java:72)
> at org.infinispan.client.hotrod.impl.operations.IterationStartOperation.executeOperation(IterationStartOperation.java:21)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56)
> at org.infinispan.client.hotrod.impl.iteration.RemoteCloseableIterator.startInternal(RemoteCloseableIterator.java:127)
> at org.infinispan.client.hotrod.impl.iteration.RemoteCloseableIterator.start(RemoteCloseableIterator.java:140)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:162)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:168)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.retrieveEntries(RemoteCacheImpl.java:173)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl$KeySet.iterator(RemoteCacheImpl.java:553)
> at org.mposolda.ispn.InfinispanRemote.main(InfinispanRemote.java:34)
> {code}
> Indeed, When looking at this line of class RemoteCacheImpl, I see that it references the class, which seem that it was added in HotRodServer version 9. This looks like the cause of the error: https://github.com/infinispan/infinispan/blob/master/client/hotrod-client...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8860) Lazy start counter's caches
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-8860?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-8860:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
integrated, thanks !
> Lazy start counter's caches
> ---------------------------
>
> Key: ISPN-8860
> URL: https://issues.jboss.org/browse/ISPN-8860
> Project: Infinispan
> Issue Type: Enhancement
> Components: Clustered Counter
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
>
> Goal: if counter's are used, there is no need to start counter's caches!
> Main change:
> * remove {{__counter_configuration}} and use the {{state-cache}} to store counter's configuration
> Summary:
> * When the first counter is defined and stored in the {{state-cache}}, the {{__counter}} cache is started.
> * When a node joins, it starts the {{__counter}} cache if it finds a counter's configured stored
> * We need to persist the counter's configuration (for persisted counters only!) manually since the {{state-cache}} isn't persisted
> Issues
> * the {{state-cache}} is available during partitions! same counter can be defined with different configuration :(
> users have to deal with it while I can't find a way to resolve a conflict.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8962) PreferAvailabilityStrategy: Rely less on the stable topology
by Dan Berindei (JIRA)
Dan Berindei created ISPN-8962:
----------------------------------
Summary: PreferAvailabilityStrategy: Rely less on the stable topology
Key: ISPN-8962
URL: https://issues.jboss.org/browse/ISPN-8962
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.2.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.3.0.Final, 9.2.1.Final
{{PreferAvailabilityStrategy}} checks the size of the stable topology, and only considers cache topologies that are derived from the biggest topology (in size) when picking a post-merge topology.
Unfortunately, in some situations this algorithm fails pretty badly. If a node has a very long GC pause, when it comes back it will report the old topology *and* the old stable topology. If the rest of the cluster rebalanced, it now has both a smaller current topology and a smaller stable topology.
Furthermore, the stable topology is updated asynchronously, independent from the current topology. So even if there's a split and the minority partition installs a current topology with fewer members, it may take some time for its stable topology to be updated with fewer members. In fact, it appears that when a rebalance is not needed (e.g. because the partition has a single node), the stable topology is never updated!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8962) PreferAvailabilityStrategy: Rely less on the stable topology
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8962?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-8962:
-------------------------------
Status: Open (was: New)
> PreferAvailabilityStrategy: Rely less on the stable topology
> ------------------------------------------------------------
>
> Key: ISPN-8962
> URL: https://issues.jboss.org/browse/ISPN-8962
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.3.0.Final, 9.2.1.Final
>
>
> {{PreferAvailabilityStrategy}} checks the size of the stable topology, and only considers cache topologies that are derived from the biggest topology (in size) when picking a post-merge topology.
> Unfortunately, in some situations this algorithm fails pretty badly. If a node has a very long GC pause, when it comes back it will report the old topology *and* the old stable topology. If the rest of the cluster rebalanced, it now has both a smaller current topology and a smaller stable topology.
> Furthermore, the stable topology is updated asynchronously, independent from the current topology. So even if there's a split and the minority partition installs a current topology with fewer members, it may take some time for its stable topology to be updated with fewer members. In fact, it appears that when a rebalance is not needed (e.g. because the partition has a single node), the stable topology is never updated!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8961) Overload merge-method on BasicCache with lifespan parameters
by S Haster (JIRA)
S Haster created ISPN-8961:
------------------------------
Summary: Overload merge-method on BasicCache with lifespan parameters
Key: ISPN-8961
URL: https://issues.jboss.org/browse/ISPN-8961
Project: Infinispan
Issue Type: Enhancement
Components: Core
Affects Versions: 8.2.8.Final
Reporter: S Haster
BasicCache has overloaded a number of Map/ConcurrentMap methods with variants which take lifespan parameters. For instance, there is now a replace(K,V, long, TimeUnit) and a replace(K,V, V, long, TimeUnit).
It would be nice if the merge-methods were overloaded in the same way.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8903 started by Ryan Emerson.
------------------------------------------
> Conflict resolution not initiated if node rejoins with same topology
> --------------------------------------------------------------------
>
> Key: ISPN-8903
> URL: https://issues.jboss.org/browse/ISPN-8903
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Final, 9.2.1.Final
>
>
> The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
> Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{C\}. P1 continues to operate and update cache entries, however P2 makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8954) StateReceiverImpl should request segments via an executor
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8954?page=com.atlassian.jira.plugin.... ]
Work on ISPN-8954 started by Ryan Emerson.
------------------------------------------
> StateReceiverImpl should request segments via an executor
> ---------------------------------------------------------
>
> Key: ISPN-8954
> URL: https://issues.jboss.org/browse/ISPN-8954
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.2.1.Final
>
>
> Currently when requesting segments an InboundTransferTask is executed in the thread calling StateReceiver::getAllReplicasForSegment. The problem with this is that InboundTransferTask::requestSegments is a blocking RPC call, which due to the synchronization used by a SegmentRequest object means that it's not possible for a segment request to be cancelled while an InboundTransferTask::requestSegment call is being executed. Furthermore, this situation is exasperated by the fact that currently the transfer tasks are created using the state transfer timeout (defualt is 4 mins), so it's possible for the calling thread to be blocked for this amount of time.
> The solution is to utilise the StateTransferExecutor to process the InboundTransferTasks so that a segment request can be cancelled during a transfer request. Also, we should utilise the remaining time of the DefaultConflictManager::ReplicaSpliterator as the upper bound on the transfer tasks.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ISPN-8903) Conflict resolution not initiated if node rejoins with same topology
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8903?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8903:
-------------------------------
Status: Open (was: New)
> Conflict resolution not initiated if node rejoins with same topology
> --------------------------------------------------------------------
>
> Key: ISPN-8903
> URL: https://issues.jboss.org/browse/ISPN-8903
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.2.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.3.0.Final, 9.2.1.Final
>
>
> The current logic in PreferAvailabilityStrategy and PreferConsistencyStrategy assumes that when a split brain occurs, the two partitions will continue to operate independently before a merge occurs.
> Consider a cluster \{A,B\} which partitions into P1 \{A\} and P2 \{C\}. P1 continues to operate and update cache entries, however P2 makes no process (possibly down to a long GC pause). When P2 merges into P1, no rebalance occurs (correct as the CH remains the same) and no conflict resolution occurs. Conflict resolution should be attempted in this scenario, as it's possible that entries have been put to P1 during the partition and therefore P2 will have stale values.
> This can be reproduced by creating two nodes, pausing one process, wait for split and then resuming the process. No CR will occur.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years