November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4979) CacheStatusResponse map uses too much memory

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4979?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4979: ------------------------------- Assignee: William Burns > CacheStatusResponse map uses too much memory > -------------------------------------------- > > Key: ISPN-4979 > URL: https://issues.jboss.org/browse/ISPN-4979 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: William Burns > Priority: Critical > Fix For: 7.1.0.Final > > > When the cluster is large and there are a log of caches, the {{CacheStatusResponse}} map on the new coordinator can get quite large. One of the problems that seems to be that the addresses in {{DefaultConsistentHash}} are duplicated on serialization, so the deserialized version occupies more memory. > We need to investigate why the objects are not "shared" by the River marshaller, and maybe work around the problem by de-duplicating the addresses in the externalizer. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4444) After state transfer, a node is able to read keys it no longer owns from its data container

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4444?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4444: ------------------------------- Assignee: Pedro Ruivo > After state transfer, a node is able to read keys it no longer owns from its data container > ------------------------------------------------------------------------------------------- > > Key: ISPN-4444 > URL: https://issues.jboss.org/browse/ISPN-4444 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.1.0.Alpha1 > > > When state transfer ends and each node receives a CH_UPDATE command from the coordinator, it first installs the new topology and then it starts invalidating entries it no longer owns. > However, there are two cases when the node can still read its stale values: > 1. If L1 is enabled, it will look in the local DataContainer first, regardless of the key's location. > 2. If L1 is disabled, but the key was removed on the new owners, the node will still look up the key in the local DataContainer after receiving a null response. > The problem can be reproduced with {{TxReadAfterLosingOwnershipTest}} and its subclasses, by replacing the {{operation.update(cache(1));}} line with {{operation.update(cache(0));}} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4982) EntryRetriever doesn't filter and convert activated values properly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4982?page=com.atlassian.jira.plugin.... ] Work on ISPN-4982 started by William Burns. ------------------------------------------- > EntryRetriever doesn't filter and convert activated values properly > ------------------------------------------------------------------- > > Key: ISPN-4982 > URL: https://issues.jboss.org/browse/ISPN-4982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.1.Final > > > See https://github.com/wburns/infinispan/commit/9734bba75792876ec43338d779a16... > It appears we don't apply either the filter or converter properly to activated entries. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4982) EntryRetriever doesn't filter and convert activated values properly

by William Burns (JIRA)

William Burns created ISPN-4982: ----------------------------------- Summary: EntryRetriever doesn't filter and convert activated values properly Key: ISPN-4982 URL: https://issues.jboss.org/browse/ISPN-4982 Project: Infinispan Issue Type: Bug Components: Core Affects Versions: 7.0.0.Final Reporter: William Burns Assignee: William Burns Fix For: 7.0.1.Final See https://github.com/wburns/infinispan/commit/9734bba75792876ec43338d779a16... It appears we don't apply either the filter or converter properly to activated entries. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4982) EntryRetriever doesn't filter and convert activated values properly

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4982?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4982: -------------------------------- Status: Open (was: New) > EntryRetriever doesn't filter and convert activated values properly > ------------------------------------------------------------------- > > Key: ISPN-4982 > URL: https://issues.jboss.org/browse/ISPN-4982 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.1.Final > > > See https://github.com/wburns/infinispan/commit/9734bba75792876ec43338d779a16... > It appears we don't apply either the filter or converter properly to activated entries. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4981) Update to Hibernate Search 5.0.0.Beta2

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4981?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4981: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Update to Hibernate Search 5.0.0.Beta2 > -------------------------------------- > > Key: ISPN-4981 > URL: https://issues.jboss.org/browse/ISPN-4981 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.1.Final > > -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4964) Map/Reduce intermittently hangs when the cache is updated during execution

by Gavin Pelissier (JIRA)

[ https://issues.jboss.org/browse/ISPN-4964?page=com.atlassian.jira.plugin.... ] Gavin Pelissier commented on ISPN-4964: --------------------------------------- I have a similar but quite specific problem. (using version 6.0.1.Final on Glassfish 3.2.1.1) Cache config is: <default> <persistence passivation="true" > <singleFile fetchPersistentState="true" ignoreModifications="false" preload="true" purgeOnStartup="false" location="/cache" > <async enabled="true"/> </singleFile> </persistence> <eviction maxEntries="50000" strategy="LIRS"/> </default> . . . Use case: Calling "Cache.values()" never returns and the CPU usage climbs by 25%. Each subsequent call increases CPU usage by 25%. In this specific case the number of actual records was +- 90000. By changing maxEntries from 50000 to 150000, the problem vanished immediately. However by doing this, it means that we keep all records in memory. > Map/Reduce intermittently hangs when the cache is updated during execution > -------------------------------------------------------------------------- > > Key: ISPN-4964 > URL: https://issues.jboss.org/browse/ISPN-4964 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.1.Final, 6.0.2.Final, 7.0.0.Final > Environment: JDK 7 (1.2.0_51) Glassfish 3.2.1.1, WildFly 8.1.0.Final > Reporter: Alexandre Nikolov > > Map/Reduce tasks on a cache with intensive write operations intermittently hangs, resulting in high CPU and Heap Memory usage. If left like that eventually it crashes the VM after multiple out of memory exceptions. > Here is a stack dump of a hanging thread: > Name: transport-thread--p3-t17 > State: RUNNABLE > Total blocked: 709 Total waited: 15 204 > Stack trace: > java.util.HashMap.hash(HashMap.java:366) > java.util.HashMap.put(HashMap.java:496) > java.util.HashSet.add(HashSet.java:217) > org.infinispan.persistence.async.AdvancedAsyncCacheLoader.process(AdvancedAsyncCacheLoader.java:81) > org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:418) > org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:403) > org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:398) > org.infinispan.distexec.mapreduce.MapReduceManagerImpl.map(MapReduceManagerImpl.java:213) > org.infinispan.distexec.mapreduce.MapReduceManagerImpl.mapAndCombineForLocalReduction(MapReduceManagerImpl.java:94) > org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.invokeMapCombineLocallyForLocalReduction(MapReduceTask.java:1162) > org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart.access$400(MapReduceTask.java:1101) > org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:1133) > org.infinispan.distexec.mapreduce.MapReduceTask$MapTaskPart$2.call(MapReduceTask.java:1129) > java.util.concurrent.FutureTask.run(FutureTask.java:262) > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > java.util.concurrent.FutureTask.run(FutureTask.java:262) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > java.lang.Thread.run(Thread.java:744) > The hanging thread keep cycling between these 2 stack entries: > java.util.HashSet.add(HashSet.java:217) > org.infinispan.persistence.async.AdvancedAsyncCacheLoader.process(AdvancedAsyncCacheLoader.java:81) > Here is the configuration for 7.x: > <?xml version="1.0" encoding="UTF-8"?> > <infinispan > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:infinispan:config:7.0 http://www.infinispan.org/schemas/infinispan-config-7.0.xsd" > xmlns="urn:infinispan:config:7.0"> > <cache-container default-cache="default"> > <jmx duplicate-domains="true"/> > <local-cache name="default"> > <eviction max-entries="5000" strategy="LIRS"/> > <persistence passivation="true" > >  > <file-store fetch-state="true" preload="true" path="/cache"> > <write-behind/> > </file-store> > </persistence> > <locking isolation="REPEATABLE_READ"/> > <transaction mode="BATCH" auto-commit="true"/> > </local-cache> > > <local-cache name="intraday"> > <expiration lifespan="86400000"/> > </local-cache> > </cache-container> > </infinispan> > The issue also happens on versions 6.x. > It happens with different combination of locking and transaction settings - that is it happens with transactional and non-transactional caches with different locking configurations. I tried all possible combinations and the issue happens intermittently on all of them. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4970) AvailabilityException and AvailabilityMode are in the wrong package

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4970?page=com.atlassian.jira.plugin.... ] Ion Savin resolved ISPN-4970. ----------------------------- Resolution: Done > AvailabilityException and AvailabilityMode are in the wrong package > ------------------------------------------------------------------- > > Key: ISPN-4970 > URL: https://issues.jboss.org/browse/ISPN-4970 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.1.Final, 7.1.0.Final > > > {{AvailabilityException}} and {{AvailabilityMode}} are in package {{org.infinispan.partionhandling}}, instead of {{org.infinispan.par*ti*tionhandling}}. > For {{AvailabilityException}}, we could create a new exception in the proper package and make the old one extend the new one, but I'm not sure how we should handle {{AvailabilityMode}}. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4970) AvailabilityException and AvailabilityMode are in the wrong package

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4970?page=com.atlassian.jira.plugin.... ] Ion Savin updated ISPN-4970: ---------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3075 > AvailabilityException and AvailabilityMode are in the wrong package > ------------------------------------------------------------------- > > Key: ISPN-4970 > URL: https://issues.jboss.org/browse/ISPN-4970 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Fix For: 7.0.1.Final, 7.1.0.Final > > > {{AvailabilityException}} and {{AvailabilityMode}} are in package {{org.infinispan.partionhandling}}, instead of {{org.infinispan.par*ti*tionhandling}}. > For {{AvailabilityException}}, we could create a new exception in the proper package and make the old one extend the new one, but I'm not sure how we should handle {{AvailabilityMode}}. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4966) Backup element in XSD should be a child of cache not just of clustered-cache

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4966?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4966: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Backup element in XSD should be a child of cache not just of clustered-cache > ---------------------------------------------------------------------------- > > Key: ISPN-4966 > URL: https://issues.jboss.org/browse/ISPN-4966 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 7.0.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.1.Final > > > The infinispan-config-7.0.xsd schema wrongfully assumes that the backup element is only valid for clustered caches whereas it is valid for all types -- This message was sent by Atlassian JIRA (v6.3.8#6338)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014