[JBoss JIRA] (ISPN-7607) Cluster expiration doesn't work in write-skew
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-7607:
---------------------------------
Summary: Cluster expiration doesn't work in write-skew
Key: ISPN-7607
URL: https://issues.jboss.org/browse/ISPN-7607
Project: Infinispan
Issue Type: Bug
Reporter: Pedro Ruivo
enable optimistic locking + write-skew + versioning in the test {{ClusterListenerReplTxTest}}
Theory: In this configuration a dummy {{Metadata}} is created for expired entries. The command {{RemoveExpiredCommand}} fails to remove the entry because the {{lifespan}} doesn't match.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7602) REST cache store lazy initialization of netty causes classloading issues
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-7602?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-7602:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> REST cache store lazy initialization of netty causes classloading issues
> ------------------------------------------------------------------------
>
> Key: ISPN-7602
> URL: https://issues.jboss.org/browse/ISPN-7602
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.CR3
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.Final
>
>
> 11:02:36,129 WARN [org.infinispan.persistence.rest.upgrade.RestTargetMigrator] (pool-5-thread-1) ISPN000277: Could not migrate key keyLoad40: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: io/netty/util/internal/TypeParameterMatcher
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.rethrowException(InvocationContextInterceptor.java:141)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.access$000(InvocationContextInterceptor.java:43)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor$1.apply(InvocationContextInterceptor.java:58)
> 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:131)
> at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:94)
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:408)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:400)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
> at org.infinispan.cache.impl.TypeConverterDelegatingAdvancedCache.get(TypeConverterDelegatingAdvancedCache.java:390)
> at org.infinispan.persistence.rest.upgrade.RestTargetMigrator$1.run(RestTargetMigrator.java:62)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NoClassDefFoundError: io/netty/util/internal/TypeParameterMatcher
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at io.netty.util.internal.JavassistTypeParameterMatcherGenerator.generate(JavassistTypeParameterMatcherGenerator.java:66)
> at io.netty.util.internal.JavassistTypeParameterMatcherGenerator.generate(JavassistTypeParameterMatcherGenerator.java:58)
> at io.netty.util.internal.TypeParameterMatcher.get(TypeParameterMatcher.java:42)
> at io.netty.util.internal.TypeParameterMatcher.find(TypeParameterMatcher.java:78)
> at io.netty.channel.SimpleChannelInboundHandler.<init>(SimpleChannelInboundHandler.java:67)
> at io.netty.channel.SimpleChannelInboundHandler.<init>(SimpleChannelInboundHandler.java:57)
> at org.infinispan.persistence.rest.RestStore$HttpResponseHandler.<init>(RestStore.java:213)
> at org.infinispan.persistence.rest.RestStore.load(RestStore.java:270)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.loadFromAllStores(PersistenceManagerImpl.java:486)
> at org.infinispan.persistence.PersistenceUtil.loadAndCheckExpiration(PersistenceUtil.java:123)
> at org.infinispan.persistence.PersistenceUtil.lambda$loadAndStoreInDataContainer$3(PersistenceUtil.java:85)
> at org.infinispan.container.DefaultDataContainer.lambda$compute$6(DefaultDataContainer.java:336)
> at java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1853)
> at org.infinispan.container.DefaultDataContainer.compute(DefaultDataContainer.java:335)
> at org.infinispan.persistence.PersistenceUtil.loadAndStoreInDataContainer(PersistenceUtil.java:76)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.loadInContext(CacheLoaderInterceptor.java:335)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:330)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitDataCommand(CacheLoaderInterceptor.java:194)
> at org.infinispan.interceptors.impl.CacheLoaderInterceptor.visitGetKeyValueCommand(CacheLoaderInterceptor.java:139)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:101)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:212)
> at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:200)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:57)
> at org.infinispan.interceptors.locking.NonTransactionalLockingInterceptor.visitDataReadCommand(NonTransactionalLockingInterceptor.java:33)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:92)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:153)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:91)
> at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
> at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:126)
> ... 12 more
> Caused by: java.lang.ClassNotFoundException: io.netty.util.internal.TypeParameterMatcher from [Module "org.infinispan:main" from local module loader @1c2c22f3 (finder: local module finder @18e8568 (roots: /home/tst/Work/JBoss/infinispan/server/integration/testsuite/target/server/node1/modules,/home/tst/Work/JBoss/infinispan/server/integration/testsuite/target/server/node1/modules/system/layers/base))]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7606) DistributedExecutorMassIndexer.executeInternal should use an existing pool
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7606?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7606:
-------------------------------
Status: Open (was: New)
> DistributedExecutorMassIndexer.executeInternal should use an existing pool
> --------------------------------------------------------------------------
>
> Key: ISPN-7606
> URL: https://issues.jboss.org/browse/ISPN-7606
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 9.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Gustavo Fernandes
> Fix For: 9.0.0.Final
>
>
> {{DistributedExecutorMassIndexer.executeInternal}} creates 2 executors:
> 1. {{new DefaultExecutorService(cache)}} implicitly creates a single-threaded executor to run tasks on the local node.
> 2. {{compositeFuture.whenCompleteAsync(consumer, Executors.newSingleThreadExecutor())}} explicitly creates a new single-threaded executor to run the consumer on.
> Neither of these executors are shut down, and rather than complicating the code to stop them properly it would be better to use an existing executor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7606) DistributedExecutorMassIndexer.executeInternal should use an existing pool
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7606:
----------------------------------
Summary: DistributedExecutorMassIndexer.executeInternal should use an existing pool
Key: ISPN-7606
URL: https://issues.jboss.org/browse/ISPN-7606
Project: Infinispan
Issue Type: Bug
Components: Embedded Querying
Affects Versions: 9.0.0.CR2
Reporter: Dan Berindei
Assignee: Gustavo Fernandes
Fix For: 9.0.0.Final
{{DistributedExecutorMassIndexer.executeInternal}} creates 2 executors:
1. {{new DefaultExecutorService(cache)}} implicitly creates a single-threaded executor to run tasks on the local node.
2. {{compositeFuture.whenCompleteAsync(consumer, Executors.newSingleThreadExecutor())}} explicitly creates a new single-threaded executor to run the consumer on.
Neither of these executors are shut down, and rather than complicating the code to stop them properly it would be better to use an existing executor.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7605) Remove version schemes hardcoding
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7605?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7605:
------------------------------------
Description:
Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}.
It could make sense to support other types of versions not based on {{long}} values.
was:
Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}.
> Remove version schemes hardcoding
> ---------------------------------
>
> Key: ISPN-7605
> URL: https://issues.jboss.org/browse/ISPN-7605
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Server
> Reporter: Gustavo Fernandes
>
> Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
> The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}.
> It could make sense to support other types of versions not based on {{long}} values.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7605) Remove version schemes hardcoding
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7605?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7605:
------------------------------------
Description:
Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}.
was:
Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
The Hot Rod protocol only supports the `NumericVersion` and throughout the code there is lots of hard casts to {{NumericVersion}}.
> Remove version schemes hardcoding
> ---------------------------------
>
> Key: ISPN-7605
> URL: https://issues.jboss.org/browse/ISPN-7605
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Server
> Reporter: Gustavo Fernandes
>
> Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
> The Hot Rod protocol only supports the {{NumericVersion}} format and throughout the code there is lots of hard casts to {{NumericVersion}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7605) Remove version schemes hardcoding
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7605?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7605:
------------------------------------
Description:
Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
The Hot Rod protocol only supports the `NumericVersion` and throughout the code there is lots of hard casts to {{NumericVersion}}.
was:
Infinispan currently has two implementations of `EntryVersion`: `NumericVersion` and `SimpleClusteredVersion`.
The Hot Rod protocol only supports the `NumericVersion` and throughout the code there is lots of hard casts to `NumericVersion`.
> Remove version schemes hardcoding
> ---------------------------------
>
> Key: ISPN-7605
> URL: https://issues.jboss.org/browse/ISPN-7605
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core, Server
> Reporter: Gustavo Fernandes
>
> Infinispan currently has two implementations of {{EntryVersion}}: {{NumericVersion}} and {{SimpleClusteredVersion}}.
> The Hot Rod protocol only supports the `NumericVersion` and throughout the code there is lots of hard casts to {{NumericVersion}}.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ISPN-7605) Remove version schemes hardcoding
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-7605:
---------------------------------------
Summary: Remove version schemes hardcoding
Key: ISPN-7605
URL: https://issues.jboss.org/browse/ISPN-7605
Project: Infinispan
Issue Type: Enhancement
Components: Core, Server
Reporter: Gustavo Fernandes
Infinispan currently has two implementations of `EntryVersion`: `NumericVersion` and `SimpleClusteredVersion`.
The Hot Rod protocol only supports the `NumericVersion` and throughout the code there is lots of hard casts to `NumericVersion`.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years