[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/…
[View More]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
[View Less]
10 years, 11 months
[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
…
[View More]> 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
[View Less]
10 years, 11 months
[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
> …
[View More] 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
[View Less]
10 years, 11 months
[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
> …
[View More] 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
[View Less]
10 years, 11 months
[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
&…
[View More]gt; 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
[View Less]
10 years, 11 months
[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
> …
[View More] 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
[View Less]
10 years, 11 months