January 2014 - infinispan-issues - Jboss List Archives

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

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-3953: ----------------------------------- I've noticed that when implementing the process operation. In my current implementation (see http://github.com/rvansa/infinispan-cachestore-jpa ) I load only all keys and then load each entry in transaction. But this is far from optimal approach. Shouldn't we rename the cachestore to infinispan-persistence-hibernate instead, then, if we start using hibernate API? I have to write to infinispan-dev for the green. > 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 > > 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3640) Extend KeyFilter facility to the whole cache

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3640?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3640: --------------------------------------- I love this idea, but let's aim at making it consistent (eventually) with all features: - CacheStore filtering operations (would be great to have a "type column" in the jdbc one for example, incredibily useful for the JPA one) - Map/Reduce jobs to operate on the subset only - queries As usual the _clear()_ operation stands out as the troublemaker. > 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 > 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3952) Upgrade to Hibernate Search 4.5.0.Final

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3952?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3952: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks! > Upgrade to Hibernate Search 4.5.0.Final > --------------------------------------- > > Key: ISPN-3952 > URL: https://issues.jboss.org/browse/ISPN-3952 > Project: Infinispan > Issue Type: Component Upgrade > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3947) HotRod client keep trying recover connections to a failed cluster

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3947: ------------------------------------ I don't think configuring a number of retries per server is a good idea, it would mean that actual timeout increases linearly with the number of servers - just like it does now. I think a total number of retries and/or a total timeout would be much better. Note that with the default configuration (i.e. `testOnBorrow == false`), only the first attempt is done on the primary owner of the key. All the other attempts use a random server. (Actually it's round-robin, but the state is shared, so for an individual thread it would look random.) A setting named `retriesPerServer` would make the me think that that's the number of retries on the server before trying another. Also, I haven't tested this, but with `testOnBorrow == true` I think the pool will catch the timeout in the ping operation and retry `maxActive` times internally, before the HotRod client does its own retrying in `RetryOnFailureOperation`. We can probably ignore it, since enabling `testOnBorrow` would be bad for performance anyway, but we should probably document it. > HotRod client keep trying recover connections to a failed cluster > ----------------------------------------------------------------- > > Key: ISPN-3947 > URL: https://issues.jboss.org/browse/ISPN-3947 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Protocols > Affects Versions: 6.0.1.Final, 7.0.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > > If an infinispan-server cluster is not longer reachable for some reason, i.e. network disconnect, the hot-rod client try to re-establish the lost connections. > The client library will retry this by a fixed calculation based on the max numbers of connections from the pool or 10 multiplied with the number of available servers. > This can lead in a very long time until the application can continue and react as it will wait for the read- or connect-timeout for each try. > To improve this behaviour there should be a configurable limit of retries per server and/or a timeout in total. > This will give the application the chance to handle a remote-cache failure and reply to the user instead of hanging for minutes (with the default settings) -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3915) Upgrade to Netty 4.x

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3915?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3915: ------------------------------------- Assignee: Norman Maurer (was: Galder Zamarreño) > Upgrade to Netty 4.x > -------------------- > > Key: ISPN-3915 > URL: https://issues.jboss.org/browse/ISPN-3915 > Project: Infinispan > Issue Type: Component Upgrade > Components: Server > Reporter: Galder Zamarreño > Assignee: Norman Maurer > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Upgrade to latest Netty 4.x version. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1127) Memory leak in CacheStoreInterceptor

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-1127?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-1127: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1059547 > Memory leak in CacheStoreInterceptor > ------------------------------------ > > Key: ISPN-1127 > URL: https://issues.jboss.org/browse/ISPN-1127 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 4.2.1.FINAL, 5.0.0.CR3 > Reporter: Sergey Kondratyev > Assignee: Galder Zamarreño > Fix For: 5.0.0.CR4, 5.0.0.FINAL > > Attachments: test-leak.tar.bz2 > > > CacheStoreInterceptor leaks org.infinispan.transaction.xa.GlobalTransaction objects. Amount of live org.infinispan.transaction.xa.GlobalTransaction objects is climbing during cache work. > It is possible due to two reasons: > 1. when cache is in async replication mode entries from both txStores and preparingTxs are never deleted (maybe like JBCACHE-1454 ?). > 2. when cache is in sync mode (I tested on dist sync mode), entries from preparingTxs are not deleted in commit method (in case no exceptions raise). > So preparingTxs are never cleaned at all. Problem with txStores appears only with async 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3948) Missing logic to add the store to the configuration for custom stores

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3948?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-3948: ------------------------------------- This is indeed quite a big issue. As a workaround, configuring the store programmatically should work. Thanks for reporting it. > Missing logic to add the store to the configuration for custom stores > --------------------------------------------------------------------- > > Key: ISPN-3948 > URL: https://issues.jboss.org/browse/ISPN-3948 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Kurt Lehrke > Assignee: Dan Berindei > Priority: Critical > > Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected. -- 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

10 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3948) Missing logic to add the store to the configuration for custom stores

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3948?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3948: -------------------------------- Priority: Critical (was: Major) > Missing logic to add the store to the configuration for custom stores > --------------------------------------------------------------------- > > Key: ISPN-3948 > URL: https://issues.jboss.org/browse/ISPN-3948 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Kurt Lehrke > Assignee: Dan Berindei > Priority: Critical > > Looking at the Parser60 class, if you specify a custom store that isn't a singleFileStore or a clusterLoader, the store doesn't get added to the configuration. I found this when I specified my own CacheLoader and it wasn't instantiated like expected. -- 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

10 years, 11 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: -------------------------------- Component/s: Loaders and Stores > 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: Mircea Markus > > 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

10 years, 11 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: -------------------------------- Assignee: Radim Vansa (was: Mircea Markus) > 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 > > 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

10 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014