[JBoss JIRA] (ISPN-11124) REPL get optimiztion isn't applied for all calls
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11124?page=com.atlassian.jira.plugi... ]
Will Burns reassigned ISPN-11124:
---------------------------------
Assignee: Will Burns
> REPL get optimiztion isn't applied for all calls
> ------------------------------------------------
>
> Key: ISPN-11124
> URL: https://issues.redhat.com/browse/ISPN-11124
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.Final
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> ISPN-5451 added in some optimizations for REPL reads to not use the interceptor stack. Unfortunately this doesn't work as we now always invoke `getCacheEntryAsync` for hotrod. We need to make sure the optimized code path is used in all cases. We also should be using non blocking methods when possible as things like expiration can block unexpectedly.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11123) Integrate Mutinity in the new api
by Katia Aresti (Jira)
Katia Aresti created ISPN-11123:
-----------------------------------
Summary: Integrate Mutinity in the new api
Key: ISPN-11123
URL: https://issues.redhat.com/browse/ISPN-11123
Project: Infinispan
Issue Type: Feature Request
Components: API
Affects Versions: 10.1.0.Final
Reporter: Katia Aresti
Mutinity API has been released in the first version.
Upgrade the new reactive api to use it
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11122) CacheMode.INVALIDATION_SYNC is being replicated
by Gustavo Lira e Silva (Jira)
Gustavo Lira e Silva created ISPN-11122:
-------------------------------------------
Summary: CacheMode.INVALIDATION_SYNC is being replicated
Key: ISPN-11122
URL: https://issues.redhat.com/browse/ISPN-11122
Project: Infinispan
Issue Type: Bug
Affects Versions: 10.1.0.Final
Reporter: Gustavo Lira e Silva
Configuring two remote caches with hotrod and CacheMode.INVALIDATION_SYNC using InfinispanServerRule, populate cache1, cache2 should contain size=0, but all cache1 is being replicated to cache2.
{code:java}
RemoteCache<String, String> cache1 = SERVER_TEST.hotrod().withServerConfiguration(builder).withClientConfiguration(clientBuilder1).create();
RemoteCache<String, String> cache2 = SERVER_TEST.hotrod().withServerConfiguration(builder).withClientConfiguration(clientBuilder2).create();
cache1.put("key", "value");
assertEquals("value", cache1.get("key"));
assertEquals(1, cache1.size());
assertEquals(0, cache2.size()); // is failling
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11121) Cache using single file store fails to start when security manager is enabled
by Paul Ferraro (Jira)
Paul Ferraro created ISPN-11121:
-----------------------------------
Summary: Cache using single file store fails to start when security manager is enabled
Key: ISPN-11121
URL: https://issues.redhat.com/browse/ISPN-11121
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.17.Final
Reporter: Paul Ferraro
After upgrading to 9.4.17.Final, caches using a single file store throw a AccessControlException on startup. This looks like a regression introduced by the fix for ISPN-9600, which no longer performs component start within a privileged action.
{noformat}
&#27;[0m&#27;[31m07:21:37,237 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 20) MSC000001: Failed to start service jboss.deployment.unit."XSiteSimpleTestCase.war".undertow-deployment: org.jboss.msc.service.StartException in service jboss.deployment.unit."XSiteSimpleTestCase.war".undertow-deployment: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)
Caused by: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.persistence.manager.PersistenceManagerImpl.start() on object of type PersistenceManagerImpl
at org.infinispan.commons.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:193)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:520)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:711)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startDependencies(BasicComponentRegistryImpl.java:552)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:505)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:711)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startDependencies(BasicComponentRegistryImpl.java:552)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:505)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:711)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startDependencies(BasicComponentRegistryImpl.java:552)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:505)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:711)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startDependencies(BasicComponentRegistryImpl.java:552)
at org.infinispan.factories.impl.BasicComponentRegistryImpl.startWrapper(BasicComponentRegistryImpl.java:505)
at org.infinispan.factories.impl.BasicComponentRegistryImpl$ComponentWrapper.running(BasicComponentRegistryImpl.java:711)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:428)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:325)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:165)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:1110)
at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:511)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:660)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:604)
at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:487)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:440)
at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:86)
at org.jboss.as.test.clustering.cluster.xsite.CacheAccessServlet.init(CacheAccessServlet.java:97)
at javax.servlet.GenericServlet.init(GenericServlet.java:180)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:117)
at org.wildfly.extension.undertow.security.RunAsLifecycleInterceptor.init(RunAsLifecycleInterceptor.java:78)
at io.undertow.servlet.core.LifecyleInterceptorInvocation.proceed(LifecyleInterceptorInvocation.java:103)
at io.undertow.servlet.core.ManagedServlet$DefaultInstanceStrategy.start(ManagedServlet.java:305)
at io.undertow.servlet.core.ManagedServlet.createServlet(ManagedServlet.java:145)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:585)
at io.undertow.servlet.core.DeploymentManagerImpl$2.call(DeploymentManagerImpl.java:556)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1504)
at io.undertow.servlet.core.DeploymentManagerImpl.start(DeploymentManagerImpl.java:598)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:97)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:78)
... 8 more
Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:182)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.infinispan.commons.util.ReflectionUtil.invokeMethod(ReflectionUtil.java:188)
... 51 more
Caused by: org.infinispan.persistence.spi.PersistenceException: ISPN000527: Maximum startup attempts exceeded for store org.infinispan.persistence.file.SingleFileStore
at org.infinispan.persistence.manager.PersistenceManagerImpl.startStore(PersistenceManagerImpl.java:1082)
at org.infinispan.persistence.manager.PersistenceManagerImpl.startWriter(PersistenceManagerImpl.java:1031)
at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$start$0(PersistenceManagerImpl.java:164)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:164)
... 56 more
Caused by: org.infinispan.persistence.spi.PersistenceException: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/clustering/target/wildfly-1/standalone/data/infinispan/web/dist.dat" "read")" in code source "(vfs:/content/XSiteSimpleTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.XSiteSimpleTestCase.war" from Service Module Loader")
at org.infinispan.persistence.file.SingleFileStore.start(SingleFileStore.java:136)
at org.infinispan.persistence.manager.PersistenceManagerImpl.lambda$startWriter$22(PersistenceManagerImpl.java:1039)
at org.infinispan.persistence.manager.PersistenceManagerImpl.startStore(PersistenceManagerImpl.java:1068)
... 60 more
Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.io.FilePermission" "/store/work/tc-work/bb15431f347cd651/testsuite/integration/clustering/target/wildfly-1/standalone/data/infinispan/web/dist.dat" "read")" in code source "(vfs:/content/XSiteSimpleTestCase.war/WEB-INF/classes <no signer certificates>)" of "ModuleClassLoader for Module "deployment.XSiteSimpleTestCase.war" from Service Module Loader")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:303)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:200)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at org.wildfly.security.manager.WildFlySecurityManager.checkRead(WildFlySecurityManager.java:368)
at java.io.File.exists(File.java:814)
at org.infinispan.persistence.file.SingleFileStore.start(SingleFileStore.java:109)
... 62 more
{noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11119) Invalidation put should load previous value from stores
by Dan Berindei (Jira)
Dan Berindei created ISPN-11119:
-----------------------------------
Summary: Invalidation put should load previous value from stores
Key: ISPN-11119
URL: https://issues.redhat.com/browse/ISPN-11119
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 10.1.0.Final, 10.0.1.Final, 9.4.17.Final, 9.3.6.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Final
A {{cache.put(key, value)}} without the {{IGNORE_RETURN_VALUES}} flag should load the previous value from the store(s) and return it.
Currently the previous value is loaded only if the originator of the put is the primary owner of the key (see {{ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand()}}).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11116:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7712, https://github.com/infinispan/infinispan/pull/7713, https://github.com/infinispan/infinispan/pull/7714
> Invalidation commands should not load the previous value from the store
> -----------------------------------------------------------------------
>
> Key: ISPN-11116
> URL: https://issues.redhat.com/browse/ISPN-11116
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final, 10.1.1.Final
>
>
> {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
> But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11118) Invalidation commands should not load the previous value from the store
by Pedro Zapata Fernandez (Jira)
Pedro Zapata Fernandez created ISPN-11118:
---------------------------------------------
Summary: Invalidation commands should not load the previous value from the store
Key: ISPN-11118
URL: https://issues.redhat.com/browse/ISPN-11118
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 11.0.0.Final, 10.1.1.Final
{{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months
[JBoss JIRA] (ISPN-11116) Invalidation commands should not load the previous value from the store
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11116?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11116:
--------------------------------
Status: Open (was: New)
> Invalidation commands should not load the previous value from the store
> -----------------------------------------------------------------------
>
> Key: ISPN-11116
> URL: https://issues.redhat.com/browse/ISPN-11116
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.6.Final, 9.4.17.Final, 10.0.1.Final, 10.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.Final, 10.1.1.Final
>
>
> {{CacheLoaderInterceptor.visitInvalidateCommand()}} loads the previous value from the store, just in case there is a {{CacheEntryInvalidated}} listener that needs the previous value. This makes invalidation mode with a shared store very costly: for every write, every node receives an invalidation command, every node reads the value from the store, and then discards it.
> But {{InvalidateCommand}} only removes entries from memory, it never removes entry from stores (either shared or private). If we don't load the previous value in the data container, there is nothing for the {{InvalidateCommand}} to do. No invalidated entry means no listener notifications, so we don't need to load the previous value or to change the behaviour of {{CacheEntryInvalidatedEvent}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 4 months