[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)
4 years, 8 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)
4 years, 8 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)
4 years, 8 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)
4 years, 8 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)
4 years, 8 months
[JBoss JIRA] (ISPN-11853) Error and Log handling in REST
by Katia Aresti (Jira)
Katia Aresti created ISPN-11853:
-----------------------------------
Summary: 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
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)
4 years, 8 months
[JBoss JIRA] (ISPN-11851) FD_SOCK should use the same bind address as TCP
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11851?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11851:
--------------------------------
Status: Open (was: New)
> FD_SOCK should use the same bind address as TCP
> -----------------------------------------------
>
> Key: ISPN-11851
> URL: https://issues.redhat.com/browse/ISPN-11851
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Core
> Affects Versions: 11.0.0.Dev05, 10.1.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> In the JGroups configuration files we ship, we use a different default for {{TCP.bind_addr}} and {{UDP.bind_addr}} than JGroups does.
> {code:xml}
> <TCP bind_addr="${jgroups.bind.address,jgroups.tcp.address:SITE_LOCAL}"/>
> <UDP bind_addr="${jgroups.bind.address,jgroups.udp.address:SITE_LOCAL}"/>
> {code}
> However, we didn't change the default for {{FD_SOCK}}, so it uses the JGroups default:
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 8 months