May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3877: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096726|https://bugzilla.redhat.com/show_bug.cgi?id=1096726] from MODIFIED to ON_QA > SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem > -------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3877 > URL: https://issues.jboss.org/browse/ISPN-3877 > Project: Infinispan > Issue Type: Patch > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64 > Reporter: Rajesh Jangam > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4 > > Attachments: PersistentQueue.java > > > We are testing the latest Infinispan 6.0 SingleFileStore version for our application. > We tend to create a lot of entries in the store and remove them when not required. > However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed. > > This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed. > We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation. > As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4236) RHQ JMX plugin causes Cache/CacheManager to report as not available

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4236?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4236: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1054165|https://bugzilla.redhat.com/show_bug.cgi?id=1054165] from MODIFIED to ON_QA > RHQ JMX plugin causes Cache/CacheManager to report as not available > ------------------------------------------------------------------- > > Key: ISPN-4236 > URL: https://issues.jboss.org/browse/ISPN-4236 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 6.0.2.Final, 7.0.0.Alpha3 > Reporter: William Burns > Assignee: William Burns > Labels: 630betablocker > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > With the update to use newer RHQ, the CacheManager and Cache sometimes report as being down when using library JMX plugin. It looks like RHQ added some additional checks which just pushes the operation time over the default of 5 seconds. This is to clean up our code a bit to make the availability check for efficient. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 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: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1043434|https://bugzilla.redhat.com/show_bug.cgi?id=1043434] from MODIFIED to ON_QA > 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 > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > 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 was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4216) Use IGNORE_RETURN_VALUES flag for inserting keys/values in M/R intermediate cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4216?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4216: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096878|https://bugzilla.redhat.com/show_bug.cgi?id=1096878] from MODIFIED to ON_QA > Use IGNORE_RETURN_VALUES flag for inserting keys/values in M/R intermediate cache > --------------------------------------------------------------------------------- > > Key: ISPN-4216 > URL: https://issues.jboss.org/browse/ISPN-4216 > Project: Infinispan > Issue Type: Bug > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > Whenever data gets inserted in intermediate cache unsafeReturnValues setting is ignored and previous value from cache is returned every time we do cache#put. We did not experience this slowdown before because we only inserted once per key in intermediate cache put. Now that we do partial batching and transfer of these keys/values, we really hit the wall there with multiple insertions. Adding IGNORE_RETURN_VALUES flag to put invocation is the key to resolve this issue. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3967?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3967: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1083017|https://bugzilla.redhat.com/show_bug.cgi?id=1083017] from MODIFIED to ON_QA > 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 was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3894: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096727|https://bugzilla.redhat.com/show_bug.cgi?id=1096727] from MODIFIED to ON_QA > SingleFileStore can optimize space usage by coalescing adjacent free entry blocks. > ---------------------------------------------------------------------------------- > > Key: ISPN-3894 > URL: https://issues.jboss.org/browse/ISPN-3894 > Project: Infinispan > Issue Type: Patch > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Environment: Oracle JDK 1.7, Windows Server 2008 R2 > Reporter: Rajesh Jangam > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4 > > Attachments: CoalesceEntries.java > > > This issue is related to issue ISPN-3877. > Here we have a use case where the size of the entries gradually keeps on increasing and then finally those entries expire. > 1. Smaller entries expire and new bigger entries start getting added > 2. These new bigger entries will not fit into the free slots (entries) created due to the expiry of smaller entries. > 3. Thus, these new bigger entries only get allocated at the end of the file resulting in growth of file size. > The optimization proposed is to: > 1. Coalesce/Combine adjacent free entries during the periodic purge cycle to create bigger/larger free entries. > 2. While allocating from an existing free entry, check if the size of the free entry is more than required for the new request being allocated. If yes, then, split the free entry into two free entries: > a. First part equal to the length being requested > This is returned as a part of the allocation activity. > b. Second part equal to the remainder of the space. > This added back as a free entry to the freeList. > Thus free space created due to expiry of smaller entries becomes available for consumption for the larger entries to some extent. > This reduces file size of the store. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4137) Transaction executed multiple times due to forwarded CommitCommand

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4137?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4137: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1080313|https://bugzilla.redhat.com/show_bug.cgi?id=1080313] from MODIFIED to ON_QA > Transaction executed multiple times due to forwarded CommitCommand > ------------------------------------------------------------------ > > Key: ISPN-4137 > URL: https://issues.jboss.org/browse/ISPN-4137 > Project: Infinispan > Issue Type: Bug > Components: State Transfer, Transactions > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > > When the {{StateTransferInterceptor}} forwards a CommitCommand for the new topology, multiple CommitCommands may be broadcast across the cluster. If the command (forwarded already from originator) times out, the transaction may be correctly finished by the first one and the application considers TX as succeeded (useSynchronizations=true), although one more Rollback is sent as well. > Then, again in STI, when the CommitCommand arrives with higher topologyId than the one used for the first TX execution, another artificial Prepare (followed by the commit) is executed - see {{STI.visitCommitCommand}}. > However, this execution may be delayed a lot and originator may have already executed another TX on the same entries. Then, this forwarded Commit will overwrite the already updated entries, causing inconsistency of data. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4207) Lock container ignores key Equivalence

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4207?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4207: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1093723|https://bugzilla.redhat.com/show_bug.cgi?id=1093723] from MODIFIED to ON_QA > Lock container ignores key Equivalence > -------------------------------------- > > Key: ISPN-4207 > URL: https://issues.jboss.org/browse/ISPN-4207 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Alpha3 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha4 > > > AbstractPerEntryLockContainer uses an EquivalentConcurrentHashMapV8 to map keys to lock. It can create issues when the key is a byte array. > edit: the Stripped*LockContainer suffers from the same problem since it uses object.hashCode(). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4240) Migrate one intermediate key/value per maxCollectorSize threshold

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4240?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4240: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096467|https://bugzilla.redhat.com/show_bug.cgi?id=1096467] from MODIFIED to ON_QA > Migrate one intermediate key/value per maxCollectorSize threshold > ----------------------------------------------------------------- > > Key: ISPN-4240 > URL: https://issues.jboss.org/browse/ISPN-4240 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > When we hit the maxCollectorSize threshold, we remove all the values from the collector and we start transferring them into the intermediary cache. But the other mapper threads keep working, and event with large collector sizes, it's very likely that the collector will be full again before we finished sending the previous batch. So we could end up with a lot of threads trying to insert maxCollectorSize values in the intermediary cache in parallel, and a lot more intermediary values in memory on each mapper node than the user would expect. > In order to alleviate this observed phenomena Dan proposed an idea to keep the maxCollectorSize threshold, but to only move a single key at a time from the collector to the intermediary cache when the threshold is hit (the least recently used one). That way, the other keys would have time to collect more values (or just run the combiner a few more times). > This way we still transfer some intermediate keys/values during map/combine phase rather than all at once at the end of that phase thus alleviating possibility of OOM. At the end of map/combine phase all remaining keys/values are of course transferred. Application users can fine tune their requirements and a specific use case using maxCollectorSize threshold. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4076) RHQ server plugin: bytesRead and bytesWritten stats are broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4076?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4076: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1073509|https://bugzilla.redhat.com/show_bug.cgi?id=1073509] from MODIFIED to ON_QA > RHQ server plugin: bytesRead and bytesWritten stats are broken > -------------------------------------------------------------- > > Key: ISPN-4076 > URL: https://issues.jboss.org/browse/ISPN-4076 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > resource path: subsystem=endpoint > and underlined connectors provides statistics: bytesRead, bytesWritten. > However plugin asks for bytes-read and bytes-written which is wrong. Small change in map in MetricsRemappingComponent is needed. > + We will remove monitoring of those statistics for REST endpoint, as this endpoint does not provide those statistics at all. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 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 May 2014