May 2016 - infinispan-issues - Jboss List Archives

[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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 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)

7 years, 12 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2016