[JBoss JIRA] (ISPN-11854) Infinispan local cache error: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start()
by Marnee DeRider (Jira)
[ https://issues.redhat.com/browse/ISPN-11854?page=com.atlassian.jira.plugi... ]
Marnee DeRider updated ISPN-11854:
----------------------------------
Description:
*Summary:*
I have upgraded a Spring boot service to Infinispan 9.4.16.Final from 5.2.20.Final. The service had two XML files. Both have local-cache entries and no other types of caches. I used the conversion script to convert them.
One was left with an empty transport element by the conversion tool. That transport element seems to have been the cause of errors preventing the service from running. I believe the defect is that the config-converter tool added empty `transport` element.
*Details: *
When we deploy and run the service, we see this warning at startup:
org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start() on object of type GlobalConfigurationManagerImpl
The above is the first warning/error we see. There is no stack trace. It shouldn't be calling GlobalConfigurationManagerImpl when we're only using local cache.
A few lines later in the log, then I see many The cache has been stopped and invocations are not allowed! errors. The last error we see is as follows. The service fails to start up successfully.
Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on <server_name>
Interestingly, we started seeing log messages containing "JGroup" after the upgrade. Since we're using local cache, we don't expect to see that. (Example: "Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!")
The culprit was I believe the empty <transport /> element as shown below. This is one of our two XML config files:
{code:java}
<infinispan
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns = "urn:infinispan:config:9.4">
<threads/>
<cache-container name = "TestCenterServiceCache">
<!-- The conversion tool added this empty "transport" element. It was not present in our old config file -->
<transport/>
<jmx domain = "org.infinispan.TestCenterServiceCache"/>
<local-cache name = "authorizedLocations">
<expiration lifespan = "3600000"/>
</local-cache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<local-cache name = "proximitySearchConfiguration">
<expiration lifespan = "86400000"/>
</local-cache>
</cache-container>
</infinispan>
{code}
Once I removed the empty <transport />, then the warnings, errors, and references to JGroup went away.
The original XML was:
{code:java}
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">
<global>
<globalJmxStatistics
cacheManagerName="TestCenterServiceCache"
jmxDomain="org.infinispan.TestCenterServiceCache"/>
</global>
<!--caching for 1 hour: 3600000 milli secs-->
<namedCache name="authorizedLocations">
<expiration lifespan="3600000"/>
</namedCache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<namedCache name="proximitySearchConfiguration">
<expiration lifespan="86400000"/>
</namedCache>
</infinispan>
{code}
In order to convert it, I updated the schema to:
{code:java}
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
{code}
before converting.
Note: When I removed the `global` element from the above before converting, then the empty `<transport />` element was not added.
Finally, as proof that the transport element was the culprit, the MBeans showed that under org.infinispan.TestCenterServiceCache -> Cache there was:
{code:java}
"org.infinispan.CONFIG(repl_sync)"
{code}
Without `<transport />`, there was:
{code:java}
"org.infinispan.CONFIG(local)"
{code}
was:
*Summary: *
I have upgraded a Spring boot service to Infinispan 9.4.16.Final from 5.2.20.Final. The service had two XML files. Both have local-cache entries and no other types of caches. I used the conversion script to convert them.
One was left with an empty transport element by the conversion tool. That transport element seems to have been the cause of errors preventing the service from running. I believe the defect is that the config-converter tool added empty `transport` element.
*Details: *
When we deploy and run the service, we see this warning at startup:
org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start() on object of type GlobalConfigurationManagerImpl
The above is the first warning/error we see. There is no stack trace. It shouldn't be calling GlobalConfigurationManagerImpl when we're only using local cache.
A few lines later in the log, then I see many The cache has been stopped and invocations are not allowed! errors. The last error we see is as follows. The service fails to start up successfully.
Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on <server_name>
~~More Info~~~
Interestingly, we started seeing log messages containing "JGroup" after the upgrade. Since we're using local cache, we don't expect to see that. (Example: "Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!")
The culprit was I believe the empty <transport /> element as shown below. This is one of our two XML config files:
{code:java}
<infinispan
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns = "urn:infinispan:config:9.4">
<threads/>
<cache-container name = "TestCenterServiceCache">
<!-- The conversion tool added this empty "transport" element. It was not present in our old config file -->
<transport/>
<jmx domain = "org.infinispan.TestCenterServiceCache"/>
<local-cache name = "authorizedLocations">
<expiration lifespan = "3600000"/>
</local-cache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<local-cache name = "proximitySearchConfiguration">
<expiration lifespan = "86400000"/>
</local-cache>
</cache-container>
</infinispan>
{code}
Once I removed the empty <transport />, then the warnings, errors, and references to JGroup went away.
The original XML was:
{code:java}
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">
<global>
<globalJmxStatistics
cacheManagerName="TestCenterServiceCache"
jmxDomain="org.infinispan.TestCenterServiceCache"/>
</global>
<!--caching for 1 hour: 3600000 milli secs-->
<namedCache name="authorizedLocations">
<expiration lifespan="3600000"/>
</namedCache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<namedCache name="proximitySearchConfiguration">
<expiration lifespan="86400000"/>
</namedCache>
</infinispan>
{code}
In order to convert it, I updated the schema to:
{code:java}
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
{code}
before converting.
Note: When I removed the `global` element from the above before converting, then the empty `<transport />` element was not added.
Finally, as proof that the transport element was the culprit, the MBeans showed that under org.infinispan.TestCenterServiceCache -> Cache there was:
{code:java}
"org.infinispan.CONFIG(repl_sync)"
{code}
Without `<transport />`, there was:
{code:java}
"org.infinispan.CONFIG(local)"
{code}
> Infinispan local cache error: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start()
> ----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-11854
> URL: https://issues.redhat.com/browse/ISPN-11854
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.4.16.Final
> Reporter: Marnee DeRider
> Priority: Major
> Labels: config-converter, local-scope-mode
>
> *Summary:*
> I have upgraded a Spring boot service to Infinispan 9.4.16.Final from 5.2.20.Final. The service had two XML files. Both have local-cache entries and no other types of caches. I used the conversion script to convert them.
> One was left with an empty transport element by the conversion tool. That transport element seems to have been the cause of errors preventing the service from running. I believe the defect is that the config-converter tool added empty `transport` element.
> *Details: *
> When we deploy and run the service, we see this warning at startup:
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start() on object of type GlobalConfigurationManagerImpl
> The above is the first warning/error we see. There is no stack trace. It shouldn't be calling GlobalConfigurationManagerImpl when we're only using local cache.
> A few lines later in the log, then I see many The cache has been stopped and invocations are not allowed! errors. The last error we see is as follows. The service fails to start up successfully.
> Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on <server_name>
> Interestingly, we started seeing log messages containing "JGroup" after the upgrade. Since we're using local cache, we don't expect to see that. (Example: "Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!")
> The culprit was I believe the empty <transport /> element as shown below. This is one of our two XML config files:
> {code:java}
> <infinispan
> xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
> xmlns = "urn:infinispan:config:9.4">
> <threads/>
> <cache-container name = "TestCenterServiceCache">
> <!-- The conversion tool added this empty "transport" element. It was not present in our old config file -->
> <transport/>
> <jmx domain = "org.infinispan.TestCenterServiceCache"/>
> <local-cache name = "authorizedLocations">
> <expiration lifespan = "3600000"/>
> </local-cache>
> <!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
> <local-cache name = "proximitySearchConfiguration">
> <expiration lifespan = "86400000"/>
> </local-cache>
> </cache-container>
> </infinispan>
> {code}
> Once I removed the empty <transport />, then the warnings, errors, and references to JGroup went away.
> The original XML was:
> {code:java}
> <?xml version="1.0" encoding="UTF-8"?>
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
> xmlns="urn:infinispan:config:5.1">
> <global>
> <globalJmxStatistics
> cacheManagerName="TestCenterServiceCache"
> jmxDomain="org.infinispan.TestCenterServiceCache"/>
> </global>
> <!--caching for 1 hour: 3600000 milli secs-->
> <namedCache name="authorizedLocations">
> <expiration lifespan="3600000"/>
> </namedCache>
> <!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
> <namedCache name="proximitySearchConfiguration">
> <expiration lifespan="86400000"/>
> </namedCache>
> </infinispan>
> {code}
> In order to convert it, I updated the schema to:
> {code:java}
> <infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> {code}
> before converting.
> Note: When I removed the `global` element from the above before converting, then the empty `<transport />` element was not added.
> Finally, as proof that the transport element was the culprit, the MBeans showed that under org.infinispan.TestCenterServiceCache -> Cache there was:
> {code:java}
> "org.infinispan.CONFIG(repl_sync)"
> {code}
> Without `<transport />`, there was:
> {code:java}
> "org.infinispan.CONFIG(local)"
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11854) Infinispan local cache error: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start()
by Marnee DeRider (Jira)
Marnee DeRider created ISPN-11854:
-------------------------------------
Summary: Infinispan local cache error: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start()
Key: ISPN-11854
URL: https://issues.redhat.com/browse/ISPN-11854
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.4.16.Final
Reporter: Marnee DeRider
*Summary: *
I have upgraded a Spring boot service to Infinispan 9.4.16.Final from 5.2.20.Final. The service had two XML files. Both have local-cache entries and no other types of caches. I used the conversion script to convert them.
One was left with an empty transport element by the conversion tool. That transport element seems to have been the cause of errors preventing the service from running. I believe the defect is that the config-converter tool added empty `transport` element.
*Details: *
When we deploy and run the service, we see this warning at startup:
org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.globalstate.impl.GlobalConfigurationManagerImpl.start() on object of type GlobalConfigurationManagerImpl
The above is the first warning/error we see. There is no stack trace. It shouldn't be calling GlobalConfigurationManagerImpl when we're only using local cache.
A few lines later in the log, then I see many The cache has been stopped and invocations are not allowed! errors. The last error we see is as follows. The service fails to start up successfully.
Caused by: org.infinispan.commons.CacheException: Initial state transfer timed out for cache org.infinispan.CONFIG on <server_name>
~~More Info~~~
Interestingly, we started seeing log messages containing "JGroup" after the upgrade. Since we're using local cache, we don't expect to see that. (Example: "Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!")
The culprit was I believe the empty <transport /> element as shown below. This is one of our two XML config files:
{code:java}
<infinispan
xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation = "urn:infinispan:config:9.4 http://www.infinispan.org/schemas/infinispan-config-9.4.xsd"
xmlns = "urn:infinispan:config:9.4">
<threads/>
<cache-container name = "TestCenterServiceCache">
<!-- The conversion tool added this empty "transport" element. It was not present in our old config file -->
<transport/>
<jmx domain = "org.infinispan.TestCenterServiceCache"/>
<local-cache name = "authorizedLocations">
<expiration lifespan = "3600000"/>
</local-cache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<local-cache name = "proximitySearchConfiguration">
<expiration lifespan = "86400000"/>
</local-cache>
</cache-container>
</infinispan>
{code}
Once I removed the empty <transport />, then the warnings, errors, and references to JGroup went away.
The original XML was:
{code:java}
<?xml version="1.0" encoding="UTF-8"?>
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">
<global>
<globalJmxStatistics
cacheManagerName="TestCenterServiceCache"
jmxDomain="org.infinispan.TestCenterServiceCache"/>
</global>
<!--caching for 1 hour: 3600000 milli secs-->
<namedCache name="authorizedLocations">
<expiration lifespan="3600000"/>
</namedCache>
<!--caching for 24 hours: 3,600,000 milliseconds/hr x 24 hours -->
<namedCache name="proximitySearchConfiguration">
<expiration lifespan="86400000"/>
</namedCache>
</infinispan>
{code}
In order to convert it, I updated the schema to:
{code:java}
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
{code}
before converting.
Note: When I removed the `global` element from the above before converting, then the empty `<transport />` element was not added.
Finally, as proof that the transport element was the culprit, the MBeans showed that under org.infinispan.TestCenterServiceCache -> Cache there was:
{code:java}
"org.infinispan.CONFIG(repl_sync)"
{code}
Without `<transport />`, there was:
{code:java}
"org.infinispan.CONFIG(local)"
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11852) Allow creation of RemoteCacheConfigurations at runtime
by Paul Ferraro (Jira)
[ https://issues.redhat.com/browse/ISPN-11852?page=com.atlassian.jira.plugi... ]
Paul Ferraro commented on ISPN-11852:
-------------------------------------
[~NadirX] Can we also include a mechanism to remove a configuration? If I create a deployment specific remote cache configuration on deploy and I'd like to be able to remove it on undeploy.
> Allow creation of RemoteCacheConfigurations at runtime
> ------------------------------------------------------
>
> Key: ISPN-11852
> URL: https://issues.redhat.com/browse/ISPN-11852
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration, Hot Rod
> Affects Versions: 11.0.0.Dev05
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> ISPN-11676 added the ability to have per-cache client configurations. It should be possible to add new configurations after a RemoteCacheManager has been started.
> {code:java}
> public void remoteCache(String name, Consumer<RemoteCacheConfigurationBuilder> builderConsumer);
> {code}
> If the `name` doesn't yet exist, a builder will be created and the `Consumer` invoked to allow configuration, as follows:
> {code:java}
> remoteCache("blah", c -> c.nearCacheMode(NearCacheMode.INVALIDATED).templateName(DefaultTemplate.DIST_SYNC));
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11853) Error and Log handling in REST
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11853?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes commented on ISPN-11853:
------------------------------------------
I am not sure if NettyRestResponse.Builder thread safety is a problem, what conclusion did you get to [~william.burns]?
> Error and Log handling in REST
> ------------------------------
>
> Key: ISPN-11853
> URL: https://issues.redhat.com/browse/ISPN-11853
> Project: Infinispan
> Issue Type: Enhancement
> Components: REST
> Affects Versions: 10.1.8.Final
> Reporter: Katia Aresti
> Assignee: Gustavo Fernandes
> Priority: Major
> Labels: rest
>
> The consistency of the errors handling in the REST endpoint is not even in all the resources, and the completion stage should deal with exceptions raised instead of throwing them directly from the method
> Logs are missing in the REST endpoints, specially trace logs, which makes debugging in production hard
> Finally the NettyRestResponse.Builder apparently is not thread safe, so would be better to make it thread safe
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11642) Remote JCacheManager doesn't apply configuration from URI
by Gustavo Lira e Silva (Jira)
[ https://issues.redhat.com/browse/ISPN-11642?page=com.atlassian.jira.plugi... ]
Gustavo Lira e Silva commented on ISPN-11642:
---------------------------------------------
thanks Tristan for the feedback
> Remote JCacheManager doesn't apply configuration from URI
> ---------------------------------------------------------
>
> Key: ISPN-11642
> URL: https://issues.redhat.com/browse/ISPN-11642
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 10.1.6.Final
> Reporter: Nathan Mittlestat
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.7.Final, 11.0.0.Dev05
>
>
> Our project is using JCache API's backed by Infinspan. This is a client-server scenario where we are configuring the Hot Rod Java Client to connect to an Infinispan server.
> We are using _javax.cache.spi.CachingProvider.getCacheManager(URI, ClassLoader, Properties)_ to obtain a _CacheManager_. The URI passed points to an infinispan XML that specifies replicated-cache-configuration as part of the configuration. However the cache created from _CacheManager.createCache()_ ends up being a local cache. This proves to be a problem when connecting to a cluster of Infinispan servers, as when other connections attempt to utilize the cached data, they connect to a different Infinispn sever that doesn't have the cached data. We have verified the XML file pointed to by the URI is on the ClassLoader passed to the _CacheManager_, and still see the same results.
> When we attempt this same scenario using embedded mode instead of client server mode, the configuration in the URI is applied correctly. We have even been able to create a cluster of embedded Infinispan servers via JGroups and confirmed the caches are replicated and not local.
> We have also attempted this scenario using Infinispan's proprietary APIs:
> _RemoteCacheManager.administration().getOrCreateCache(String name, BasicConfiguration configuration)_
> The configuration object passed to _RemoteCacheManagerAdmin.getOrCreateCache()_ loads the same Infinispan XML configuration used in the failing remote JCache scenario (as a _XMlStringConfiguration_ object).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11642) Remote JCacheManager doesn't apply configuration from URI
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11642?page=com.atlassian.jira.plugi... ]
Tristan Tarrant commented on ISPN-11642:
----------------------------------------
Hmm, that got truncated and I cannot seem to edit it.
The last property shoud be
infinispan.client.hotrod.cache.testJCacheAPI2.template=org.infinispan.REPL_SYNC
or
infinispan.client.hotrod.cache.testJCacheAPI2.configuration=<infinispan> <cache-container> <replicated-cache name="testJCacheAPI2"/></cache-container></infinispan>
> Remote JCacheManager doesn't apply configuration from URI
> ---------------------------------------------------------
>
> Key: ISPN-11642
> URL: https://issues.redhat.com/browse/ISPN-11642
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 10.1.6.Final
> Reporter: Nathan Mittlestat
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.7.Final, 11.0.0.Dev05
>
>
> Our project is using JCache API's backed by Infinspan. This is a client-server scenario where we are configuring the Hot Rod Java Client to connect to an Infinispan server.
> We are using _javax.cache.spi.CachingProvider.getCacheManager(URI, ClassLoader, Properties)_ to obtain a _CacheManager_. The URI passed points to an infinispan XML that specifies replicated-cache-configuration as part of the configuration. However the cache created from _CacheManager.createCache()_ ends up being a local cache. This proves to be a problem when connecting to a cluster of Infinispan servers, as when other connections attempt to utilize the cached data, they connect to a different Infinispn sever that doesn't have the cached data. We have verified the XML file pointed to by the URI is on the ClassLoader passed to the _CacheManager_, and still see the same results.
> When we attempt this same scenario using embedded mode instead of client server mode, the configuration in the URI is applied correctly. We have even been able to create a cluster of embedded Infinispan servers via JGroups and confirmed the caches are replicated and not local.
> We have also attempted this scenario using Infinispan's proprietary APIs:
> _RemoteCacheManager.administration().getOrCreateCache(String name, BasicConfiguration configuration)_
> The configuration object passed to _RemoteCacheManagerAdmin.getOrCreateCache()_ loads the same Infinispan XML configuration used in the failing remote JCache scenario (as a _XMlStringConfiguration_ object).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months
[JBoss JIRA] (ISPN-11642) Remote JCacheManager doesn't apply configuration from URI
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11642?page=com.atlassian.jira.plugi... ]
Tristan Tarrant commented on ISPN-11642:
----------------------------------------
[~nmittles] after my fix, this will work, but not using the procedure you describe.
The URI you must pass is that of a hotrod-client.properties file. This file now supports supplying a cache configuration/template using the following properties:
infinispan.client.hotrod.cache._cachename_.configuration=<xml>
or
infinispan.client.hotrod.cache._cachename_.template=template name (like org.infinispan.REPL_SYNC)
Note that this doesn't yet support cache names with "." in them (like you use in the example).
{code:java}
import java.io.File;
import java.net.URI;
import java.util.ArrayList;
import java.util.Properties;
import javax.cache.CacheManager;
import javax.cache.Caching;
import javax.cache.configuration.MutableConfiguration;
import javax.cache.expiry.EternalExpiryPolicy;
public class InfinispanRemoteTest {
public static void main(String[] args) throws Exception {
File hrProps = new File("./hotrod-jcache.properties");
URI uri = hrProps.toURI();
Properties vendorProperties = new Properties();
MutableConfiguration<String, ArrayList> config = new MutableConfiguration<String, ArrayList>()
.setTypes(String.class, ArrayList.class)
.setExpiryPolicyFactory(EternalExpiryPolicy.factoryOf()); cacheManager = Caching.getCachingProvider().getCacheManager(uri, Thread.currentThread().getContextClassLoader(), vendorProperties);
//TestJCache API
cacheManager.createCache("testJCacheAPI2", config);
}
}
{code}
hotrod.properties:
{code:java}
infinispan.client.hotrod.server_list=localhost:11222
infinispan.client.hotrod.marshaller=org.infinispan.commons.marshall.JavaSerializationMarshaller
infinispan.client.hotrod.java_serial_whitelist=.*
infinispan.client.hotrod.auth_username=username
infinispan.client.hotrod.auth_password=password
infinispan.client.hotrod.auth_realm=default
infinispan.client.hotrod.sasl_mechanism=DIGEST-MD5
infinispan.client.hotrod.auth_server_name=infinispan
infinispan.client.hotrod.cache.com.myproject.testJCacheAPI2
{code}
> Remote JCacheManager doesn't apply configuration from URI
> ---------------------------------------------------------
>
> Key: ISPN-11642
> URL: https://issues.redhat.com/browse/ISPN-11642
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 10.1.6.Final
> Reporter: Nathan Mittlestat
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.1.7.Final, 11.0.0.Dev05
>
>
> Our project is using JCache API's backed by Infinspan. This is a client-server scenario where we are configuring the Hot Rod Java Client to connect to an Infinispan server.
> We are using _javax.cache.spi.CachingProvider.getCacheManager(URI, ClassLoader, Properties)_ to obtain a _CacheManager_. The URI passed points to an infinispan XML that specifies replicated-cache-configuration as part of the configuration. However the cache created from _CacheManager.createCache()_ ends up being a local cache. This proves to be a problem when connecting to a cluster of Infinispan servers, as when other connections attempt to utilize the cached data, they connect to a different Infinispn sever that doesn't have the cached data. We have verified the XML file pointed to by the URI is on the ClassLoader passed to the _CacheManager_, and still see the same results.
> When we attempt this same scenario using embedded mode instead of client server mode, the configuration in the URI is applied correctly. We have even been able to create a cluster of embedded Infinispan servers via JGroups and confirmed the caches are replicated and not local.
> We have also attempted this scenario using Infinispan's proprietary APIs:
> _RemoteCacheManager.administration().getOrCreateCache(String name, BasicConfiguration configuration)_
> The configuration object passed to _RemoteCacheManagerAdmin.getOrCreateCache()_ loads the same Infinispan XML configuration used in the failing remote JCache scenario (as a _XMlStringConfiguration_ object).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 10 months