April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4214) Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4214?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4214: ----------------------------------------------- Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1088214|https://bugzilla.redhat.com/show_bug.cgi?id=1088214] from NEW to MODIFIED > Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute > ---------------------------------------------------------------------------------------- > > Key: ISPN-4214 > URL: https://issues.jboss.org/browse/ISPN-4214 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final, 7.0.0.Alpha3 > Reporter: Martin Gencur > Assignee: Martin Gencur > Labels: 630betablocker > Fix For: 7.0.0.Alpha4 > > > This will be a problem when the server gets rebased to latest WildFly components - where it will fail to parse the whole configuration due to an exception being thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4248) Rethink L1OnRehash to another implementation

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4248?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4248: -------------------------------- Summary: Rethink L1OnRehash to another implementation (was: Rething L1OnRehash to another implementation) > Rethink L1OnRehash to another implementation > -------------------------------------------- > > Key: ISPN-4248 > URL: https://issues.jboss.org/browse/ISPN-4248 > Project: Infinispan > Issue Type: Feature Request > Components: L1 > Affects Versions: 6.0.2.Final > Reporter: William Burns > Assignee: Dan Berindei > > L1OnRehash currently has some issues with timings with a concurrent modification. As such it has been removed for ISPN 7.0 to be reimplemented in another fashion. It was removed in ISPN-3838. There has been some discussion around it on the mailing list here: > http://lists.jboss.org/pipermail/infinispan-dev/2014-January/014434.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4248) Rething L1OnRehash to another implementation

by William Burns (JIRA)

William Burns created ISPN-4248: ----------------------------------- Summary: Rething L1OnRehash to another implementation Key: ISPN-4248 URL: https://issues.jboss.org/browse/ISPN-4248 Project: Infinispan Issue Type: Feature Request Components: L1 Affects Versions: 6.0.2.Final Reporter: William Burns Assignee: Dan Berindei L1OnRehash currently has some issues with timings with a concurrent modification. As such it has been removed for ISPN 7.0 to be reimplemented in another fashion. It was removed in ISPN-3838. There has been some discussion around it on the mailing list here: http://lists.jboss.org/pipermail/infinispan-dev/2014-January/014434.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3838: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2530 > L1 entry added by ST when already invalidated > --------------------------------------------- > > Key: ISPN-3838 > URL: https://issues.jboss.org/browse/ISPN-3838 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > > Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1. > 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries > 2. Write on primary owner (B) occurs > 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore) > 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container. > Result: Outdated value is in L1 cache. > As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value). > (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3953) JPACacheStore should not load all entities in memory

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3953: -------------------------------- Labels: 630 630betablocker (was: 630) > JPACacheStore should not load all entities in memory > ---------------------------------------------------- > > Key: ISPN-3953 > URL: https://issues.jboss.org/browse/ISPN-3953 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Emmanuel Bernard > Assignee: Radim Vansa > Labels: 630, 630betablocker > Fix For: 7.0.0.Alpha3 > > > Today several methods use getResultList() and load either all keys or all entities for a given entity type in- memory at the same time. > This will likely blow up for big tables. > There are two solutions: > ## Use Hibernate's specific features > Hibernate ORM has a session.scroll() method that offers a FORWARD_ONLY scrollable result set. You can then load data and regularly (every 100?) clear the session before hitting the next result. This will diminish greatly the memory pressure. > ## Use a window model > get the number of entities in the table select count(*) > Then use setFirstResult / setMaxResults to navigate the data with a sliding window and clear the session every time you move the window. > This won't be as efficient as Hibernate ORM's specific approach but will do the work except on database that don't support the ability to start the results at the nth element. Look up Hibernate dialects for more info. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4187) LRU eviction algorithm does not evict the eldest entry

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4187?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4187: -------------------------------- Labels: 630betablocker (was: ) > LRU eviction algorithm does not evict the eldest entry > ------------------------------------------------------ > > Key: ISPN-4187 > URL: https://issues.jboss.org/browse/ISPN-4187 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 7.0.0.Alpha2 > Reporter: Martin Gencur > Assignee: William Burns > Labels: 630betablocker > Fix For: 7.0.0.Alpha4 > > Attachments: server2.log > > > The following test for JDBC cache stores fails: > {code:java} > @Test > @WithRunningServer({@RunningServer(name = CONTAINER1, config = CONFIG_FETCH_STATE_1)}) > public void testFetchState() throws Exception { > try { > mc1 = createMemcachedClient(server1); > assertCleanCacheAndStore1(); > mc1.set("k1", "v1"); > mc1.set("k2", "v2"); > mc1.set("k3", "v3"); > assertNotNull(dbServer1.stringTable.getValueByKey("k1")); > startContainer(controller, CONTAINER2, CONFIG_FETCH_STATE_2); > mc2 = createMemcachedClient(server2); > assertTrue(0 < server2.getCacheManager(MANAGER_NAME).getCache(CACHE_NAME).getNumberOfEntries()); > //the cache store should fetch state from the others > //since eviction.max-entries==2, first k2 and k3 is loaded from the other cache, then k1 is loaded > //from the other cache's loader and thus k2 is evicted and ends up in a cache loader > assertNull(dbServer2.stringTable.getValueByKey("k1")); > assertEquals("v1", mc2.get("k1")); > assertEquals("v2", mc2.get("k2")); > assertNull(dbServer2.stringTable.getValueByKey("k1")); > //^^^^^fails here, the K1 was evicted even though it was used recently > //K3 was supposed to be evicted but it did not happen > assertNull(dbServer2.stringTable.getValueByKey("k2")); > assertCleanCacheAndStore2(); > } finally { > controller.stop(CONTAINER2); > } > } > {code} > This tests works properly if the following commit is reverted, so it was caused by this commit: > https://github.com/infinispan/infinispan/commit/b190230d84beb41474bae0239... > Note that there's another commit with the same name but different commit hash: b71da1c > The test above can be run from https://github.com/chepa653/infinispan/tree/t_ISPN-3904 by going to server/integration/testsuite and running mvn clean verify -Dtest=StringBasedStoreMultinodeTest#testFetchState -Dlog.level.infinispan=TRACE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4061) JPA Cache Store fails on Oracle, Postgres and MsSQL

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4061?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4061: -------------------------------- Labels: 630 630betablocker (was: 630) > JPA Cache Store fails on Oracle, Postgres and MsSQL > --------------------------------------------------- > > Key: ISPN-4061 > URL: https://issues.jboss.org/browse/ISPN-4061 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Labels: 630, 630betablocker > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > Current snapshot version of JPA Cache Store fails on Oracle (see [failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...] with stack traces), Postgres ([failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...]) and MsSQL ([failed tests|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/infinispan-jpa...]). > While in case of Oracle and Postgres the problem is probably in {{\_\_ispn_metadata\_\_}} table, in case of MsSQL problem is in "User" entity, as User is reserved name in MsSQL. Oracle has a problem with table starting with underscrore, in case of Postgres {{VARBINARY}} type used in {{\_\_ispn_metadata\_\_}} is not available in. In case of MsSQL I'm not completely sure if it's bug or if it should be handled by user. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4214) Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4214?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4214: -------------------------------- Labels: 630betablocker (was: ) > Custom cache store and cache loader sets SHARED attribute to the value of NAME attribute > ---------------------------------------------------------------------------------------- > > Key: ISPN-4214 > URL: https://issues.jboss.org/browse/ISPN-4214 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Final, 7.0.0.Alpha3 > Reporter: Martin Gencur > Assignee: Martin Gencur > Labels: 630betablocker > Fix For: 7.0.0.Alpha4 > > > This will be a problem when the server gets rebased to latest WildFly components - where it will fail to parse the whole configuration due to an exception being thrown. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3967) Create a feature file for HotRod client for easy installation in Karaf

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3967?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3967: -------------------------------- Labels: 630 630betablocker (was: 630) > Create a feature file for HotRod client for easy installation in Karaf > ---------------------------------------------------------------------- > > Key: ISPN-3967 > URL: https://issues.jboss.org/browse/ISPN-3967 > Project: Infinispan > Issue Type: Feature Request > Reporter: Martin Gencur > Assignee: Martin Gencur > Labels: 630, 630betablocker > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > A "feature" file is a descriptor of bundles required by a feature. (More info at http://icodebythesea.blogspot.cz/2012/03/making-osgi-deployments-easier-w...) > We should provide such a file for easy deployment on Karaf. Otherwise users will have to install all artifacts one by one (jboss-loggin, jgroups, infinispan-commons, infinispan-core, commons-pool, jboss-marshalling-osgi, ...) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3838) L1 entry added by ST when already invalidated

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3838?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3838: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from NEW to POST > L1 entry added by ST when already invalidated > --------------------------------------------- > > Key: ISPN-3838 > URL: https://issues.jboss.org/browse/ISPN-3838 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Labels: 620 > > Non-transactional cache with L1 enabled. Node A is losing ownership of an entry, the entry is not removed during ST but is going to L1. > 1. ST builds the invalidation command, EntryWrapping interceptor starts committing all the entries > 2. Write on primary owner (B) occurs > 3. A gets the InvalidateL1Command, removes the ImmortalCacheEntry from data container (as it does not own the entry anymore) > 4. The ST invalidation command commits the MortalCacheEntry with old value, storing it into the data container. > Result: Outdated value is in L1 cache. > As the entry is not locked during the ST, it can be committed as MortalCacheEntry only if it was not changed (removed and possibly then cached again with different value). > (I understand that this wouldn't be easy to implement as the check is not to be executed in perform, but during the actual commit - and atomically in the container.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

9 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 April 2014