May 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6574: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.2.Final Resolution: Done > JCache CacheManger need to know about existing caches if remote (HotRod) is used > -------------------------------------------------------------------------------- > > Key: ISPN-6574 > URL: https://issues.jboss.org/browse/ISPN-6574 > Project: Infinispan > Issue Type: Bug > Components: JCache > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API. > Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also. > Excerpt from API Doc: > ------------------------------------ > K,V> Cache<K,V> getCache(String cacheName, > Class<K> keyType, > Class<V> valueType) > Looks up a managed Cache given its name. > This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified. > Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method. > Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail. > Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null. > Parameters: > cacheName - the name of the managed Cache to acquire > keyType - the expected Class of the key > valueType - the expected Class of the value > Returns: > the Cache or null if it does exist or can't be pre-configured > Throws: > IllegalStateException - if the CacheManager is isClosed() > IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache. > SecurityException - when the operation could not be performed due to the current security settings -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6563: ---------------------------------- Fix Version/s: 8.2.2.Final > If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6563 > URL: https://issues.jboss.org/browse/ISPN-6563 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults. > But it is expected that the hotrod-client.properties are used to configure the remote connection. > The code is like this: > { > import javax.cache.*; > ... > CachingProvider jcacheProvider = Caching.getCachingProvider(); > CacheManager cacheManager = jcacheProvider.getCacheManager(); > } > The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties. > Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6563: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties > ------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-6563 > URL: https://issues.jboss.org/browse/ISPN-6563 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final > > > If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults. > But it is expected that the hotrod-client.properties are used to configure the remote connection. > The code is like this: > { > import javax.cache.*; > ... > CachingProvider jcacheProvider = Caching.getCachingProvider(); > CacheManager cacheManager = jcacheProvider.getCacheManager(); > } > The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties. > Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6516) Update aesh to 0.66.4

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-6516?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-6516: ------------------------------ Fix Version/s: 9.0.0.Alpha2 8.2.2.Final > Update aesh to 0.66.4 > --------------------- > > Key: ISPN-6516 > URL: https://issues.jboss.org/browse/ISPN-6516 > Project: Infinispan > Issue Type: Bug > Reporter: Vaclav Dedik > Assignee: Tristan Tarrant > Fix For: 9.0.0.Alpha2, 8.2.2.Final > > > I believe this package (aesh) needs to be aligned to wildfly 10/eap 7, which uses 0.66.4/0.66.4.redhat-1. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HRJS-9) Remove listener not working in cluster

by Galder Zamarreño (JIRA)

Galder Zamarreño created HRJS-9: ----------------------------------- Summary: Remove listener not working in cluster Key: HRJS-9 URL: https://issues.jboss.org/browse/HRJS-9 Project: Infinispan Javascript client Issue Type: Bug Affects Versions: 0.2.0 Reporter: Galder Zamarreño Removing listener not working in a cluster. The problem is most likely due to routing since the remove listener should remove it from the node where it was added, so it needs to keep around the node address where the client listener add was invoked. Right now there's no such guarantee. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HRJS-8) Add encrypted transport support

by Galder Zamarreño (JIRA)

Galder Zamarreño created HRJS-8: ----------------------------------- Summary: Add encrypted transport support Key: HRJS-8 URL: https://issues.jboss.org/browse/HRJS-8 Project: Infinispan Javascript client Issue Type: Feature Request Reporter: Galder Zamarreño Add encrypted socket communication support. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6573) Functional API does not work [correctly] in transaction context

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6573?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6573: --------------------------------------- Attachment: AbstractFunctionalInMemoryTest.java FunctionalInMemoryTestTx.java FunctionalInMemoryTestNonTx.java Answering to https://developer.jboss.org/message/955416#955416 ("Is this an issue only when cache store is involved, or are the functional operations broken in transactional mode completely?"): yes, it's broken in transactional mode completely. I'm attaching tests that illustrate this. FunctionalInMemoryNonTx passes, while FunctionalInMemoryTx fails. > Functional API does not work [correctly] in transaction context > --------------------------------------------------------------- > > Key: ISPN-6573 > URL: https://issues.jboss.org/browse/ISPN-6573 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.1.Final > Reporter: Krzysztof Sobolewski > Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalInMemoryTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java, FunctionalInMemoryTestNonTx.java, FunctionalInMemoryTestTx.java > > > What is needed: a functional write operation on a key on a node that is not the key's owner, with cache loader enabled. What happens then is in non-transactional context it works fine; It starts failing when the functional operation is done in a transaction. Looks like the entry is wrapped prematurely, which puts it into the context's looked up nodes with the null value; the cache loader skips because the key is not local; and when it reaches Command.perform(), it still has null value. In the non-tx context this works OK because the command returns early if the entry is null (not wrapped) and then it is properly sent across the cluster. But in tx context it gets confused and invokes the functional operation on the local node even if it's not the owner. The functional operation gets an empty entry even though the cache loader would load it. It then modifies the entry, but the modification is not propagated anywhere because the tx distribution interceptor... well, because it doesn't handle this command at all? And the change is (apparently) not committed on the local node because it's not an owner. > Oh, and if the node *is* an owner it doesn't help :) > The tests are also available at https://gist.github.com/ksobolew/74bb8ff6b321786e64a62ecd0e4c5878/836905d... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6576?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski commented on ISPN-6576: -------------------------------------------- Yes, that's the problem. I assume the idea of this API is that the function is replicated to all the owners (primary and backup) and executed there, modifying the local value, without the need to replicate the result (or, actually, to *avoid* the replication of final values). That way I can achieve what deltas would do - the function is the delta, in other words. > Functional API does not load values from cache loader on non-primary owners > --------------------------------------------------------------------------- > > Key: ISPN-6576 > URL: https://issues.jboss.org/browse/ISPN-6576 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.1.Final > Reporter: Krzysztof Sobolewski > Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java > > > We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See: > org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand() > line 53. > This is using non-transactional cache. > NOTE: The attached tests are modified version of the ones in ISPN-6573. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6576) Functional API does not load values from cache loader on non-primary owners

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6576?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6576: --------------------------------------- Attachment: AbstractFunctionalCachestoreTest.java Slightly modified test case with better filtering of owners and non-owners. > Functional API does not load values from cache loader on non-primary owners > --------------------------------------------------------------------------- > > Key: ISPN-6576 > URL: https://issues.jboss.org/browse/ISPN-6576 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.1.Final > Reporter: Krzysztof Sobolewski > Attachments: AbstractFunctionalCachestoreTest.java, AbstractFunctionalCachestoreTest.java, FunctionalCachestoreTestNonTx.java, FunctionalCachestoreTestTx.java > > > We have a cluster in DIST mode with numOwners > 1, so there are primary and secondary owners, with persistence enabled. When I do a read-write operation on the cluster using the Functional API on a key that is present in the cache loader, the entry that gets passed to the functional operation has a non-null value only for the primary owner. See: > org.infinispan.interceptors.ClusteredCacheLoaderInterceptor.skipLoadForWriteCommand() > line 53. > This is using non-transactional cache. > NOTE: The attached tests are modified version of the ones in ISPN-6573. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016