January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3956) L1WriteSynchronizer can cause locking with concurrent gets when value is not present

by William Burns (JIRA)

William Burns created ISPN-3956: ----------------------------------- Summary: L1WriteSynchronizer can cause locking with concurrent gets when value is not present Key: ISPN-3956 URL: https://issues.jboss.org/browse/ISPN-3956 Project: Infinispan Issue Type: Bug Reporter: William Burns Assignee: Mircea Markus This has been seen previously only on IBM JDK 6 ISPN-3889, however an end user also now can reproduce this issue https://community.jboss.org/thread/236590 The issue is that we don't set the remove lookup value to be null when nothing is found and thus any threads that are waiting for the remote lookup were never notified of this. -- 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, 6 months

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3953?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3953: --------------------------------------- +1 for the Hibernate specific approach: the window model has some big drawbacks: - select count() can be extremely slow (It takes 40 minutes on my local wikipedia) - needs to lock the full table to be accurate (and you don't have an API to do that) - if the underlying rdbms doesn't support pagination, it's going to beg for mercy > JPACacheStore should not load all entities in memory > ---------------------------------------------------- > > Key: ISPN-3953 > URL: https://issues.jboss.org/browse/ISPN-3953 > Project: Infinispan > Issue Type: Enhancement > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3955) Add JavaDoc for various DummyInMemoryStore classes

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3955?page=com.atlassian.jira.plugin.... ] William Burns reassigned ISPN-3955: ----------------------------------- Assignee: William Burns (was: Dan Berindei) > Add JavaDoc for various DummyInMemoryStore classes > -------------------------------------------------- > > Key: ISPN-3955 > URL: https://issues.jboss.org/browse/ISPN-3955 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Core > Reporter: William Burns > Assignee: William Burns > > We have the DummyInMemoryStore which is for use with tests. However this class and it's supporting configuration etc do not have java doc to explain what the various parameters do. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3955) Add JavaDoc for various DummyInMemoryStore classes

by William Burns (JIRA)

William Burns created ISPN-3955: ----------------------------------- Summary: Add JavaDoc for various DummyInMemoryStore classes Key: ISPN-3955 URL: https://issues.jboss.org/browse/ISPN-3955 Project: Infinispan Issue Type: Enhancement Components: Documentation-Core Reporter: William Burns Assignee: Dan Berindei We have the DummyInMemoryStore which is for use with tests. However this class and it's supporting configuration etc do not have java doc to explain what the various parameters do. -- 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, 6 months

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3947?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3947: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2360 > 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, 6 months

1
0
0 / 0

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

by Emmanuel Bernard (JIRA)

Emmanuel Bernard created ISPN-3953: -------------------------------------- Summary: JPACacheStore should not load all entities in memory Key: ISPN-3953 URL: https://issues.jboss.org/browse/ISPN-3953 Project: Infinispan Issue Type: Enhancement 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3954) Use Hibernate's StatelessSession for the JPACacheStore

by Emmanuel Bernard (JIRA)

Emmanuel Bernard created ISPN-3954: -------------------------------------- Summary: Use Hibernate's StatelessSession for the JPACacheStore Key: ISPN-3954 URL: https://issues.jboss.org/browse/ISPN-3954 Project: Infinispan Issue Type: Enhancement Reporter: Emmanuel Bernard Assignee: Mircea Markus The current model uses the regular session even though operations are tailored toward actions (insert, update, delete). It would be better to make use of the Hibernate StatelessSession API which has been designed for these use cases. -- 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, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3951) Make sure TestingUtil.replaceComponent is only called after mock is fully configured

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3951?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3951: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2359 > Make sure TestingUtil.replaceComponent is only called after mock is fully configured > ------------------------------------------------------------------------------------ > > Key: ISPN-3951 > URL: https://issues.jboss.org/browse/ISPN-3951 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 6.0.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1, 7.0.0.Final > > > Some of our tests replace existing components. Unfortunately these could be replaced with mocks that aren't fully initialized until the next line. This can cause spurious test failures. -- 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, 6 months

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3952?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated ISPN-3952: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2358 > 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, 6 months

1
0
0 / 0

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

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-3952: ------------------------------------- Summary: 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, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2014