July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4536) Purge method in JPACacheStore will go in OOM

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4536: ------------------------------------- Summary: Purge method in JPACacheStore will go in OOM Key: ISPN-4536 URL: https://issues.jboss.org/browse/ISPN-4536 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa The purge method in ScrollableResults iterates on all results in the database without ever clearing the EntityManager. This will bring servers down with OOM if your database is large enough. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4535) size() operator on JPACacheStore should expect larger than int

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4535: ------------------------------------- Summary: size() operator on JPACacheStore should expect larger than int Key: ISPN-4535 URL: https://issues.jboss.org/browse/ISPN-4535 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa the return type of the CacheStore#size() is int but it's common in databases to store way more. The query performing the count operation is doing a cast to integer, this will fail. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4534) Allow storage of mapped graphs in JPACacheStore

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4534: ------------------------------------- Summary: Allow storage of mapped graphs in JPACacheStore Key: ISPN-4534 URL: https://issues.jboss.org/browse/ISPN-4534 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa While we can't store relations among different entities stored in different Infinispan entries, it is possible that someone stores a single entry which has embedded types. That would map correctly to the database but all of the other types need to be known the the EntityManager too. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4533) Support composite key identifiers

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4533: ------------------------------------- Summary: Support composite key identifiers Key: ISPN-4533 URL: https://issues.jboss.org/browse/ISPN-4533 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa The current JPACacheStore doesn't support composite keys, like having multiple attributed annotated with @Id, but this should be possible to implement as any composite key is expected to have a corresponding "wrapper class" which encloses each attribute. This wrapper class would be the identifier for Infinispan too. The reasonable limitation is that such a key often (but not exclusively) implies a relation with other entities. As in all other cases we can't allow deletion / creation of other related things to be reordered, but that is no reason to ban composite keys altogether as these are very common for other purposes too. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4532) Support multiple entity types in the JPACacheStore

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4532: ------------------------------------- Summary: Support multiple entity types in the JPACacheStore Key: ISPN-4532 URL: https://issues.jboss.org/browse/ISPN-4532 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa I think it's reasonable to expect to be able to store multiple types in the same Cache, especially if there is the goal to run an eviction process which picks the optimal eviction among many types. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4531) Checking against usage of @GeneratedValue annotation bypasses XML configuration

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4531: ------------------------------------- Summary: Checking against usage of @GeneratedValue annotation bypasses XML configuration Key: ISPN-4531 URL: https://issues.jboss.org/browse/ISPN-4531 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa Priority: Minor There is a verification against using the @GeneratedValue annotation on the model's primary key, but this can be configured via an XML configuration too. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4530) Allow for usage of @GeneratedValue in read only models of the JPACacheStore

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4530: ------------------------------------- Summary: Allow for usage of @GeneratedValue in read only models of the JPACacheStore Key: ISPN-4530 URL: https://issues.jboss.org/browse/ISPN-4530 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa There is no reason to disallow usage of @GeneratedValue if the model is meant to be read exclusively. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4529) Avoid serializing key for storage of metadata in JPACacheStore

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-4529: ------------------------------------- Summary: Avoid serializing key for storage of metadata in JPACacheStore Key: ISPN-4529 URL: https://issues.jboss.org/browse/ISPN-4529 Project: Infinispan Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Loaders and Stores Reporter: Sanne Grinovero Assignee: Radim Vansa We don't need to define a MetadataEntity in advance which uses byte[] as a primary key, we could generate the entity as a dynamic definition using the same key of the object. That gets us: - better storage efficiency - no need to unmarshall/marshall - options for cascade delete or inline update In fact the whole MetadataEntity could (if the user doesn't mind changing his tables) be incorporated in the entity itself. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4478) ServerFailureRetrySingleOwnerTest can have issues creating cache managers

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4478?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-4478: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ServerFailureRetrySingleOwnerTest can have issues creating cache managers > ------------------------------------------------------------------------- > > Key: ISPN-4478 > URL: https://issues.jboss.org/browse/ISPN-4478 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 7.0.0.Alpha5 > > > {code} > java.lang.RuntimeException: Timed out before caches had complete views. Expected 3 members in each view. Views are as follows: [[ServerFailureRetrySingleOwnerTest-NodeD-62958, ServerFailureRetrySingleOwnerTest-NodeE-52896], [ServerFailureRetrySingleOwnerTest-NodeE-52896, ServerFailureRetrySingleOwnerTest-NodeF-14197], [ServerFailureRetrySingleOwnerTest-NodeE-52896, ServerFailureRetrySingleOwnerTest-NodeF-14197]] > at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:268) > at org.infinispan.test.TestingUtil.viewsTimedOut(TestingUtil.java:258) > at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:250) > at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:291) > at org.infinispan.test.TestingUtil.blockUntilViewsReceived(TestingUtil.java:922) > at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:226) > at org.infinispan.test.MultipleCacheManagersTest.waitForClusterToForm(MultipleCacheManagersTest.java:233) > at org.infinispan.client.hotrod.retry.AbstractRetryTest.createCacheManagers(AbstractRetryTest.java:63) > at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:70) > at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:80) > at org.infinispan.client.hotrod.HitsAwareCacheManagersTest.createBeforeMethod(HitsAwareCacheManagersTest.java:35) > {code} > In the logs, you see messages like this: > {code} > [22:43:33] : [org.infinispan:infinispan-client-hotrod] 22:43:33,977 ERROR [StateConsumerImpl] (transport-thread-ServerFailureRetrySingleOwnerTest-NodeE-p848-t1:) ISPN000208: No live owners found for segment 0 of cache __cluster_registry_cache__. Current owners are: [ServerFailureRetrySingleOwnerTest-NodeD-62958]. Faulty owners: [ServerFailureRetrySingleOwnerTest-NodeD-62958] > [22:43:33] : [org.infinispan:infinispan-client-hotrod] 22:43:33,977 ERROR [StateConsumerImpl] (transport-thread-ServerFailureRetrySingleOwnerTest-NodeE-p848-t1:) ISPN000208: No live owners found for segment 1 of cache __cluster_registry_cache__. Current owners are: [ServerFailureRetrySingleOwnerTest-NodeD-62958]. Faulty owners: [ServerFailureRetrySingleOwnerTest-NodeD-62958] > [22:43:33] : [org.infinispan:infinispan-client-hotrod] 22:43:33,977 ERROR [StateConsumerImpl] (transport-thread-ServerFailureRetrySingleOwnerTest-NodeE-p848-t1:) ISPN000208: No live owners found for segment 2 of cache __cluster_registry_cache__. Current owners are: [ServerFailureRetrySingleOwnerTest-NodeD-62958]. Faulty owners: [ServerFailureRetrySingleOwnerTest-NodeD-62958] > [22:43:33] : [org.infinispan:infinispan-client-hotrod] 22:43:33,977 ERROR [StateConsumerImpl] (transport-thread-ServerFailureRetrySingleOwnerTest-NodeE-p848-t1:) ISPN000208: No live owners found for segment 3 of cache __cluster_registry_cache__. Current owners are: [ServerFailureRetrySingleOwnerTest-NodeD-62958]. Faulty owners: [ServerFailureRetrySingleOwnerTest-NodeD-62958] > [22:43:33] : [org.infinispan:infinispan-client-hotrod] 22:43:33,977 ERROR [StateConsumerImpl] (transport-thread-ServerFailureRetrySingleOwnerTest-NodeE-p848-t1:) ISPN000208: No live owners found for segment 4 of cache __cluster_registry_cache__. Current owners are: [ServerFailureRetrySingleOwnerTest-NodeD-62958]. Faulty owners: [ServerFailureRetrySingleOwnerTest-NodeD-62958] > {code} > The fact that after each method a cache manager is created might be causing issues here. > According to test ServerFailureRetrySingleOwnerTest.testRetryPutIfAbsent runs fine and the next time createBeforeMethod is called, the issue appears. > By doing creating the cache managers a single time, on test class startup, we should be able to speed up execution too. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2932) Verify that preloading a read only index in a cache will never hit the cacheloader

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-2932?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-2932: ------------------------------------ Description: With a warm cache (with no eviction) we should never need to hit the CacheLoader again. Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) I'm suspecting demand of null valued entries. mailing list thread: http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012261.html was: With a warm cache (with no eviction) we should never need to hit the CacheLoader again. Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) I'm suspecting demand of null valued entries. > Verify that preloading a read only index in a cache will never hit the cacheloader > ---------------------------------------------------------------------------------- > > Key: ISPN-2932 > URL: https://issues.jboss.org/browse/ISPN-2932 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > > With a warm cache (with no eviction) we should never need to hit the CacheLoader again. > Was reported - specifically with DIST on multiple nodes - that occasionall IO is triggered; we should add tests to verify this doesn't happen (or to understand why it should) > I'm suspecting demand of null valued entries. > mailing list thread: http://lists.jboss.org/pipermail/infinispan-dev/2013-March/012261.html -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014