[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3894:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2336
Added a git pull request:
https://github.com/infinispan/infinispan/pull/2336
> 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: Mircea Markus
> 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 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
12 years, 2 months
[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 Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam commented on ISPN-3877:
-------------------------------------
Added a pull request: https://github.com/infinispan/infinispan/pull/2335
> 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: Galder Zamarreño
> 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 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
12 years, 2 months
[JBoss JIRA] (ISPN-3894) SingleFileStore can optimize space usage by coalescing adjacent free entry blocks.
by Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3894?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3894:
--------------------------------
Forum Reference: https://community.jboss.org/message/851958#851958
> 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: Mircea Markus
> 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 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
12 years, 2 months
[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 Rajesh Jangam (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
Rajesh Jangam updated ISPN-3877:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/2335
> 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: Galder Zamarreño
> 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 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
12 years, 2 months
[JBoss JIRA] (ISPN-3895) Compilation with Java 1.6.0_65 fails
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3895?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3895:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 7.0.0.Alpha1
7.0.0.Final
Resolution: Done
> Compilation with Java 1.6.0_65 fails
> -------------------------------------
>
> Key: ISPN-3895
> URL: https://issues.jboss.org/browse/ISPN-3895
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 7.0.0.Final
> Reporter: Valerio Schiavoni
> Assignee: Tristan Tarrant
> Fix For: 7.0.0.Alpha1, 7.0.0.Final
>
>
> I'm trying to follow the 'Getting started with Infinispan' as published here:
> http://infinispan.org/docs/6.0.x/getting_started/getting_started.html
> There, it is specified: "A Java 6.0 JDK"
> Compiling INFINISPAN-7.0.0-SNAPSHOT with Maven 3.1.1 and java version "1.6.0_65, the maven-enforcer-plugin complains:
> [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-enforcer-plugin:1.0:enforce' with basic configurator -->
> [DEBUG] (s) fail = true
> [DEBUG] (s) failFast = false
> [DEBUG] (f) ignoreCache = false
> [DEBUG] (s) project = MavenProject: org.infinispan:infinispan-parent:7.0.0-SNAPSHOT @ /Users/veleno/workspace-git/infinispan/parent/pom.xml
> [DEBUG] (s) version = [1.7,)
> [DEBUG] (s) version = [3.0.3,)
> [DEBUG] (s) rules = [org.apache.maven.plugins.enforcer.RequireJavaVersion@15194a34, org.apache.maven.plugins.enforcer.RequireMavenVersion@2f56a6be]
> [DEBUG] (s) session = org.apache.maven.execution.MavenSession@7b681460
> [DEBUG] (s) skip = false
> [DEBUG] -- end configuration --
> [DEBUG] Executing rule: org.apache.maven.plugins.enforcer.RequireJavaVersion
> [DEBUG] Rule org.apache.maven.plugins.enforcer.RequireJavaVersion is cacheable.
> [DEBUG] Detected Java String: 1.6.0_65
> [DEBUG] Normalized Java String: 1.6.0-65
> [DEBUG] Parsed Version: Major: 1 Minor: 6 Incremental: 0 Build: 65 Qualifier: null
> [DEBUG] Adding failure due to exception
> org.apache.maven.enforcer.rule.api.EnforcerRuleException: Detected JDK Version: 1.6.0-65 is not in the allowed range [1.7,).
> at org.apache.maven.plugins.enforcer.AbstractVersionEnforcer.enforceVersion(AbstractVersionEnforcer.java:101)
> at org.apache.maven.plugins.enforcer.RequireJavaVersion.execute(RequireJavaVersion.java:65)
> at org.apache.maven.plugins.enforcer.EnforceMojo.execute(EnforceMojo.java:186)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:317)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:152)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> $java -version:
> java version "1.6.0_65"
> Java(TM) SE Runtime Environment (build 1.6.0_65-b14-462-11M4609)
> Java HotSpot(TM) 64-Bit Server VM (build 20.65-b04-462, mixed mode)
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3901) Drop AtomicMap (and FineGrainedAtomicMap)
by Galder Zamarreño (JIRA)
Galder Zamarreño created ISPN-3901:
--------------------------------------
Summary: Drop AtomicMap (and FineGrainedAtomicMap)
Key: ISPN-3901
URL: https://issues.jboss.org/browse/ISPN-3901
Project: Infinispan
Issue Type: Enhancement
Reporter: Galder Zamarreño
Assignee: Mircea Markus
* Paul not using it any more for AS/Wildfly
* Atomic Maps lose data and don’t work well with replication queue
* Instead, Paul using Grouping API now
* [~sannegrinovero] and OGM, do you still need atomic maps? Could grouping API be used instead?
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-694) Create expiration notification for in-memory cache entries
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ]
Galder Zamarreño commented on ISPN-694:
---------------------------------------
CacheStore interfaces have now been enhanced in order to support this use case better.
In the future, we might want to do it differently if we bring in tombstone support. IOW, even if the data has been expired and passivated, the metadata and key remain in memory, and then when processing expired entries, the memory contains both information on the expired entries both in memory and in the persistent store.
> Create expiration notification for in-memory cache entries
> ----------------------------------------------------------
>
> Key: ISPN-694
> URL: https://issues.jboss.org/browse/ISPN-694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Eviction
> Environment: any
> Reporter: Edouard Boily
> Assignee: Galder Zamarreño
> Attachments: 01.patch
>
>
> Create a CacheEntryExpired notification and make EvictionManager send this notification when a cache entry is evicted because it is expired.
> Also mage sure the cache entry value is sent over in the event.
> CacheEntryEvicted notification should also send the entry value in the event.
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3640) Extend KeyFilter facility to the whole cache
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3640?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3640:
----------------------------------------
There's quite a few benefits on this:
* It allows you to store multiple types in the same cache in a type-safe way.
* It would allow for queries on different types to work with a single cache (currently queries can only be executed on a single cache).
* For transactional caches, it'd be more performant to have a single cache with multiple types, that a cache for each type and get them to cooperate on the same transaction.
* Filtering applied by cache view could be done earlier on in the stack that any filtering that is applied at the cache listener level.
* Iteration would need some work to make sure that it only iterates over entries that pass the filter.
> Extend KeyFilter facility to the whole cache
> --------------------------------------------
>
> Key: ISPN-3640
> URL: https://issues.jboss.org/browse/ISPN-3640
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
>
> The key filter facility is very convenient for users who have multiple key types in the same cache. It would be very handy if this feature were extended to the whole cache.
> e.g.
> Cache<?, ?> cache = ...;
> KeyFilter filter = ...;
> Cache<K, V> view = cache.filter(filter);
> view.addListener(listener) // Equivalent to the current cache.addListener(listener, filter) method
> for (Map.Entry<K, V> entry: view.entrySet()) {
> ...
> }
--
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
12 years, 2 months
[JBoss JIRA] (ISPN-3355) Add support for clustered listeners
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3355?page=com.atlassian.jira.plugin.... ]
William Burns reassigned ISPN-3355:
-----------------------------------
Assignee: William Burns (was: Mircea Markus)
> Add support for clustered listeners
> -----------------------------------
>
> Key: ISPN-3355
> URL: https://issues.jboss.org/browse/ISPN-3355
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
> Assignee: William Burns
>
> As opposed to the current listener approach in Infinispan ( a listener instance is invoked on the data owners ), this JIRA is about adding support for a cluster listener: the same listener instance that is notified disregarding of data ownership ( RPC calls involved).
> Due to the fact that the listener notification might involve an RPC, it is nice to be able to specify filters on these listeners.
> The clustered listener support opens the way for some interesting architectures:
> * persistent/continuous queries: the query is transformed in a filter. On each notification, the listener (stateful) updates the query state
> * simplistic CEP can be built on top of the persistent query described above
> * remote/hotrod notifications might be based on clustered listeners as well.
--
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
12 years, 2 months