[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)
7 years, 9 months
[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)
7 years, 9 months
[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)
7 years, 9 months
[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)
7 years, 9 months
[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)
7 years, 9 months
[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)
7 years, 9 months
[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)
7 years, 9 months
[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7586:
------------------------------------
Description:
Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
Clients can see the following situation:
{code:java}
client.put("K","value")
// will get "V" back
client.get("K")
// Deletes will not propagate to the source cluster,
// the RemoteStore is in 'read-only' mode.
client.remove("K")
// Returns "V". Although deleted, value will be retrieved
// from the remote store
cache.get("K")
{code}
This can break existing application that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store.
was:
Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
Clients can see the following situation:
{code:java}
client.put("K","value")
// will get "V" back
client.get("K")
// Deletes will not propagate to the source cluster,
// the RemoteStore is in 'read-only' mode.
client.remove("K")
// Returns "V". Although deleted, value will be retrieved
// from the remote store
cache.get("K")
{code}
> Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7586
> URL: https://issues.jboss.org/browse/ISPN-7586
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
>
> Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
> Clients can see the following situation:
> {code:java}
> client.put("K","value")
> // will get "V" back
> client.get("K")
> // Deletes will not propagate to the source cluster,
> // the RemoteStore is in 'read-only' mode.
> client.remove("K")
> // Returns "V". Although deleted, value will be retrieved
> // from the remote store
> cache.get("K")
>
> {code}
> This can break existing application that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7586) Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7586?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7586:
------------------------------------
Description:
Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
Clients can see the following situation:
{code:java}
client.put("K","value")
// will get "V" back
client.get("K")
// Deletes will not propagate to the source cluster,
// the RemoteStore is in 'read-only' mode.
client.remove("K")
// Returns "V". Although deleted, value will be retrieved
// from the remote store
cache.get("K")
{code}
This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store.
was:
Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
Clients can see the following situation:
{code:java}
client.put("K","value")
// will get "V" back
client.get("K")
// Deletes will not propagate to the source cluster,
// the RemoteStore is in 'read-only' mode.
client.remove("K")
// Returns "V". Although deleted, value will be retrieved
// from the remote store
cache.get("K")
{code}
This can break existing application that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store.
> Rolling Upgrade: use of Remote Store in mode read-only causes data inconsistencies
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7586
> URL: https://issues.jboss.org/browse/ISPN-7586
> Project: Infinispan
> Issue Type: Bug
> Reporter: Gustavo Fernandes
>
> Assuming a Hot Rod client pointing to the target cluster. Target cluster has a {{RemoteStore}} pointing to the source cluster in read-only mode.
> Clients can see the following situation:
> {code:java}
> client.put("K","value")
> // will get "V" back
> client.get("K")
> // Deletes will not propagate to the source cluster,
> // the RemoteStore is in 'read-only' mode.
> client.remove("K")
> // Returns "V". Although deleted, value will be retrieved
> // from the remote store
> cache.get("K")
>
> {code}
> This can break existing applications that expect a transparent and consistent access to data during a Rolling Upgrade process. Clearly the remote store should be in non-read only mode for clients iteration but at the same time it should not allow the Rolling Upgrade itself to cause writes back to the remote store.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months