[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-7572:
------------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/4974, https://github.com/infinispan/infinispan/pull/4999, https://github.com/infinispan/infinispan/pull/4981 (was: https://github.com/infinispan/infinispan/pull/4974)
> Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions
> --------------------------------------------------------------------------------------------
>
> Key: ISPN-7572
> URL: https://issues.jboss.org/browse/ISPN-7572
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores, Lucene Directory, WildFly modules
> Affects Versions: 8.2.6.Final, 9.0.0.CR2
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Critical
> Fix For: 9.0.0.Final, 8.2.7.Final
>
>
> When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL).
> In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions.
> This will cause puzzling errors such as :
> {{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}}
> For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past:
> Explicit classloader support during parsing was introduced in 2013:
> - http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html
> Then removed again in 2014:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html
> I asked for improvements and hoped for someone to take ownership:
> - http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html
> In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did.
> Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL.
> My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them.
> In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them.
> But [~NadirX] doesn't like that, so assigning the issue to him ;-)
> Alternative ideas:
> * allow people to mention module names explicitly in the Infinispan configuration?
> * have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI
> I favour the second option, especially as it came up before as a dire pratical need for many other situations.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7657) Administration console - Indexing tab allows invalid configuration to be set
by Roman Macor (JIRA)
Roman Macor created ISPN-7657:
---------------------------------
Summary: Administration console - Indexing tab allows invalid configuration to be set
Key: ISPN-7657
URL: https://issues.jboss.org/browse/ISPN-7657
Project: Infinispan
Issue Type: Bug
Components: JMX, reporting and management
Affects Versions: 9.0.0.CR3
Reporter: Roman Macor
Setting indexing for invalidation cache is not a valid configuration, but the console allows this configuration.
Part of the server log after restart:
...
org.infinispan.commons.CacheConfigurationException: ISPN000273: Indexing can not be enabled on caches in Invalidation mode
...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7628:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> Administration console - the cluster status doesn't reflect "reload-required" state of its nodes
> ------------------------------------------------------------------------------------------------
>
> Key: ISPN-7628
> URL: https://issues.jboss.org/browse/ISPN-7628
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Fix For: 9.0.0.Final
>
>
> The cluster has "Started" status even though all of its nodes have "reload-required" status.
> Expected result:
> The cluster status should also be "reload-required"
> Another suggestion:
> "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them )
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7644:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Fix For: 9.0.0.Final
>
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7637) Administration console - Store config change fails if wb is enabled, modal is opened and no value changed.
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-7637?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-7637:
--------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Final
Resolution: Done
> Administration console - Store config change fails if wb is enabled, modal is opened and no value changed.
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7637
> URL: https://issues.jboss.org/browse/ISPN-7637
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
> Priority: Minor
> Fix For: 9.0.0.Final
>
>
> The issue is that when the user opens one of the pop-up dialogs in cache configuration (e.g. cache store -> Write behind), doesn't change anything and clicks OK, make some other changes, there is an error pop up when they try to save changes.
> Steps to reproduce:
> Set up a file store:
> Cache container -> cache -> configuration -> Store tab -> Select file store -> apply -> ok -> restart later
> Make a change:
> - Cache container -> cache -> configuration -> Store tab
> - change an attribute e.g. Read Only
> - click on write behind (Don't change anything) -> click OK (WORKAROUND: if we click Cancel here instead of OK, everything works fine)
> - apply changes -> confirm
> result:
> Error pop-up:
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-5":"WFLYCTL0201: Unknown attribute 'modified'"}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7652) Incorrect River marshaller in server
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-7652?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-7652:
----------------------------------------
For reference: I was unable to replicate same issue in master. It turns out that the "jboss-marshalling-osgi" package also contains the River classes. Even so, both master and 8.2.x end up shipping River marshaller 1.4.10 jars in its own module. The fact that master does not probably means that River marshaller 1.4.x module does not end up getting imported by the Infinispan Hot Rod layer, whereas in 8.2.x it somehow does and hence the River marshaller classes in "jboss-marshalling-osgi" module get mixed up.
I didn't know but server/integration/bin directory contains some scripts to help with module dependencies. After talking to [~NadirX], he's agreed to take over since he's more knowledgeable on all this module business, because a question to ask is whether the River marshaller module jar could be ignored or trimmed, but having had a quick look to the module dependencies, seems like some Wildfly internals use it.
> Incorrect River marshaller in server
> ------------------------------------
>
> Key: ISPN-7652
> URL: https://issues.jboss.org/browse/ISPN-7652
> Project: Infinispan
> Issue Type: Task
> Components: Marshalling, Server
> Affects Versions: 8.2.6.Final, 9.0.0.CR3
> Reporter: Galder Zamarreño
> Assignee: Tristan Tarrant
> Fix For: 9.0.0.CR4, 8.2.7.Final
>
>
> After upgrading JBoss Marshalling to 2.0.0.Beta3, we forgot to apply similar changes to force JBoss Marshaller's River to be in sync. As a result, the server currently ships River 1.4.10 version which causes issues mentioned [here|https://github.com/infinispan/infinispan/pull/4709]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7655) Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
by Katia Aresti (JIRA)
[ https://issues.jboss.org/browse/ISPN-7655?page=com.atlassian.jira.plugin.... ]
Katia Aresti updated ISPN-7655:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5007
> Calling Primitives.writeRawPrimitive with char raises java.lang.ClassCastException
> ----------------------------------------------------------------------------------
>
> Key: ISPN-7655
> URL: https://issues.jboss.org/browse/ISPN-7655
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.CR3
> Environment: Found the problem with a unit test on vertx-infinispan projet that was failing
> Reporter: Katia Aresti
> Assignee: Katia Aresti
> Fix For: 9.0.0.Final
>
>
> java.lang.ClassCastException: java.lang.Character cannot be cast to java.lang.Integer
> at org.infinispan.marshall.core.Primitives.writeRawPrimitive(Primitives.java:89)
> at org.infinispan.marshall.core.Primitives.writePrimitive(Primitives.java:71)
> at org.infinispan.marshall.core.JBossMarshallerTest.testTT(JBossMarshallerTest.java:118)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:348)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:127)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months
[JBoss JIRA] (ISPN-7644) Administration console - Loader tab allows invalid configuration to be set.
by Roman Macor (JIRA)
[ https://issues.jboss.org/browse/ISPN-7644?page=com.atlassian.jira.plugin.... ]
Roman Macor commented on ISPN-7644:
-----------------------------------
[~ryanemerson] it seems it happens with every cache loader except for "Single files store", I thought it was all of them.
Try setting another loader e.g. String Based JDBC Store
Server log after restart:
ERROR [org.jboss.as.clustering.infinispan] (MSC service thread 1-5) DGISPN0016: Waiting for deployment of Custom Cache Store (org.infinispan.persistence.jdbc.stringbased.JdbcStringBasedStore) timed out. Please check if this cache store is really present.
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.datagrid-infinispan.clustered.repl: org.jboss.msc.service.StartException in service jboss.datagrid-infinispan.clustered.repl: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
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: 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.invokeAccessibly(ReflectionUtil.java:172)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:635)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:624)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:549)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:231)
at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:803)
at org.infinispan.cache.impl.AbstractDelegatingCache.start(AbstractDelegatingCache.java:411)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:652)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:592)
at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:456)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:446)
at org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager.getCache(AbstractDelegatingEmbeddedCacheManager.java:139)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:133)
at org.infinispan.server.infinispan.SecurityActions$5.run(SecurityActions.java:130)
at org.infinispan.security.Security.doPrivileged(Security.java:76)
at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:66)
at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:138)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:86)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
... 3 more
Caused by: org.infinispan.commons.CacheException: Unable to start cache loaders
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:194)
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.invokeAccessibly(ReflectionUtil.java:168)
... 23 more
Caused by: org.infinispan.commons.CacheConfigurationException: ISPN000249: The cache loader configuration org.jboss.as.clustering.infinispan.cs.configuration.DeployedStoreConfiguration does not specify the loader class using @ConfigurationFor
at org.infinispan.persistence.factory.ConfigurationForClassExtractor.getClassBasedOnConfigurationAnnotation(ConfigurationForClassExtractor.java:21)
at org.infinispan.persistence.factory.LocalClassLoaderCacheStoreFactory.createInstance(LocalClassLoaderCacheStoreFactory.java:21)
at org.infinispan.persistence.factory.CacheStoreFactoryRegistry.createInstance(CacheStoreFactoryRegistry.java:39)
at org.infinispan.persistence.manager.PersistenceManagerImpl.createLoadersAndWriters(PersistenceManagerImpl.java:591)
at org.infinispan.persistence.manager.PersistenceManagerImpl.start(PersistenceManagerImpl.java:149)
> Administration console - Loader tab allows invalid configuration to be set.
> ---------------------------------------------------------------------------
>
> Key: ISPN-7644
> URL: https://issues.jboss.org/browse/ISPN-7644
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 9.0.0.CR2
> Reporter: Roman Macor
> Assignee: Ryan Emerson
>
> Click on cache container -> cache -> configuration -> loader tab
> Some options in loader type drop down such as "Async Cache loader" (but there might be more of them) result in following error, after cluster restart:
> ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 19) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "datagrid-infinispan"),
> ("cache-container" => "clustered"),
> ("configurations" => "CONFIGURATIONS"),
> ("distributed-cache-configuration" => "distributedCache")
> ]) - failure description: "DGISPN0102: org.infinispan.persistence.async.AsyncCacheLoader is not a valid cache store"
> Then there are valid options such as "Single File Store" which work if there is a corresponding cache store set up, in this case, File store. But if there isn't a cache store configured, the cache is no longer available after restart and configuration cannot be fixed from the console.
> I suggest we add a restriction when configuring cache loaders in the console which wouldn't allow the users to configure cache loader without having to configure appropriate cache store first.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 9 months