[JBoss JIRA] (ISPN-5028) BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-5028?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-5028:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3121, https://github.com/infinispan/infinispan/pull/3127 (was: https://github.com/infinispan/infinispan/pull/3127)
> BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned random failures
> --------------------------------------------------------------------------
>
> Key: ISPN-5028
> URL: https://issues.jboss.org/browse/ISPN-5028
> Project: Infinispan
> Issue Type: Bug
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.1.0.Beta1
>
>
> {noformat}
> 01:40:35,536 ERROR (testng-LocalEntryRetrieverEvictionTest:) [UnitTestTestNGListener] Test testExpiredEntryNotReturned(org.infinispan.iteration.LocalEntryRetrieverEvictionTest) failed.
> java.lang.AssertionError: expected:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, 3=3 stay in cache, 4=4 stay in cache}> but was:<{0=0 stay in cache, 1=1 stay in cache, 2=2 stay in cache, expired=this shouldn't be returned, 3=3 stay in cache, 4=4 stay in cache}>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.iteration.BaseEntryRetrieverEvictionTest.testExpiredEntryNotReturned(BaseEntryRetrieverEvictionTest.java:56)
> {noformat}
> The problem is that the test measures the time expired since _before_ inserting the value, it should measure the time since _after_ inserting the value (actually {{Thread.sleep()}} would suffice). Computing the time since before the insert is only useful when check that the entry didn't expire too soon.
> I have seen a failure in {{LocalEntryRetrieverEvictionTest}} on my machine, but only failures in {{ReplicatedEntryRetrieverEvictionTest}} and {{DistributedEntryRetrieverEvictionTest}} in CI:
> http://ci.infinispan.org/viewLog.html?buildId=14438&tab=buildResultsDiv&b...
> http://ci.infinispan.org/viewLog.html?buildId=14568&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (ISPN-5159) Make concurrent startup smooth
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-5159?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-5159:
---------------------------------------
+1
Long time ago I would use the JGroups option {{org.jgroups.protocols.Discovery.num_initial_members}} but this is being ignored now. Not sure why JGroups dropped the feature - probably not a problem for JGroups users but it's a problem for Infinispan users to not have a similar strategy.
> Make concurrent startup smooth
> ------------------------------
>
> Key: ISPN-5159
> URL: https://issues.jboss.org/browse/ISPN-5159
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.1.0.Beta1
> Reporter: Radim Vansa
>
> When starting many instances in parallel, it often happens that the node does not detect its neighborhood very well and this results in many subclusters, merging views etc.
> Merging two available partitions has undefined results (AFAIK). While we can expect that there are no requests to the cluster from the application ^1^, Infinispan itself uses some caches to store internal information (HotRod routing, Protobuf etc...). It would be better if the available-available merge would provide hooks for rebuilding this info.
> ^1^) Being able to start the cluster with reads/writes disabled and enable them only when the cache has expected number of members would be convenient, too.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (ISPN-4842) Reduce the overhead of clustered caches
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4842?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4842:
---------------------------------------
As discussed face to face, I think it's time to reconsider the asymmetric Caches idea.
Just make them all initialized eagerly, don't allow starting new caches after the CacheManager has started, but make it easier for people to start multiple (independent) CacheManager(s) on a FORKed JGroups channel.
This would also require for the same application (classloader and classes) to be available on each node participating in the CacheManager group; that's not a drawback but a benefit: would allow us to load many more extensions points to the CacheManager from the user context: from Infinispan configuration files but up to custom interceptors et al.
> Reduce the overhead of clustered caches
> ---------------------------------------
>
> Key: ISPN-4842
> URL: https://issues.jboss.org/browse/ISPN-4842
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 7.0.0.CR1
> Reporter: Takayoshi Kimura
>
> A user is testing 500 nodes cluster with 500 dist caches defined, and plans to expand it to 3000 caches.
> Infinispan manages consistent hash per cache, uses a JGroups channel per cache and uses several threads per cache. It gives significant overhead with this large size cluster. When tested with this size, Infinispan easily exhausted all threads in the thread pools and deadlocks, and requires several thousands threads to handle massive JOIN requests - the coord receives 499 * 3000 JOIN requests.
> It would be great if we can share the consistent hash and resources between caches. For example, define a "master" dist cache and allow other caches to refer to the master cache for resource sharing.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-5131:
--------------------------------------
Description:
h2. Overview
Support the deployment and configuration of a custom cache store.
h2. Client Perspective
In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
h2. Implementation overview
The implementation is based on Deployable Filters and Converters.
Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning.
h2. Implementation doubts and questions:
* Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
** YES, we should expose all of them.
* How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
** Using {{org.infinispan.server.endpoint.subsystem.EndpointSubsystemAdd}}
was:
h2. Overview
Support the deployment and configuration of a custom cache store.
h2. Client Perspective
In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
h2. Implementation overview
The implementation is based on Deployable Filters and Converters.
Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning.
h2. Implementation doubts and questions:
* Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
** YES, we should expose all of them.
* How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
**
> Deploy custom cache store to Infinispan Server
> ----------------------------------------------
>
> Key: ISPN-5131
> URL: https://issues.jboss.org/browse/ISPN-5131
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Server
> Reporter: Tristan Tarrant
> Assignee: Sebastian Łaskawiec
> Fix For: 7.2.0.Final
>
>
> h2. Overview
> Support the deployment and configuration of a custom cache store.
> h2. Client Perspective
> In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
> h2. Implementation overview
> The implementation is based on Deployable Filters and Converters.
> Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning.
> h2. Implementation doubts and questions:
> * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
> ** YES, we should expose all of them.
> * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
> ** Using {{org.infinispan.server.endpoint.subsystem.EndpointSubsystemAdd}}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-5131:
--------------------------------------
Description:
h2. Overview
Support the deployment and configuration of a custom cache store.
h2. Client Perspective
In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
h2. Implementation overview
The implementation is based on Deployable Filters and Converters.
Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning.
h2. Implementation doubts and questions:
* Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
** YES, we should expose all of them.
* How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
**
was:
h2. Overview
Support the deployment and configuration of a custom cache store.
h2. Client Perspective
In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
h2. Implementation overview
The implementation is based on Deployable Filters and Converters.
Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{LoadWriteStoreRegistry}}, which will contain a list of {{AdvancedLoadWriteStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{AdvancedLoadWriteStoreFactories}} will be added after deployment scanning.
h2. Implementation doubts and questions:
* Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
* How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
> Deploy custom cache store to Infinispan Server
> ----------------------------------------------
>
> Key: ISPN-5131
> URL: https://issues.jboss.org/browse/ISPN-5131
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Server
> Reporter: Tristan Tarrant
> Assignee: Sebastian Łaskawiec
> Fix For: 7.2.0.Final
>
>
> h2. Overview
> Support the deployment and configuration of a custom cache store.
> h2. Client Perspective
> In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
> h2. Implementation overview
> The implementation is based on Deployable Filters and Converters.
> Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning.
> h2. Implementation doubts and questions:
> * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
> ** YES, we should expose all of them.
> * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
> **
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-5131:
-------------------------------------------
Answering my own question - this approach doesn't make sense. The main problem here is to instantiate a CacheLoader/Writer based on {{ConfigureFor}} annotation. This is the most important part of this implementation.
> Deploy custom cache store to Infinispan Server
> ----------------------------------------------
>
> Key: ISPN-5131
> URL: https://issues.jboss.org/browse/ISPN-5131
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores, Server
> Reporter: Tristan Tarrant
> Assignee: Sebastian Łaskawiec
> Fix For: 7.2.0.Final
>
>
> h2. Overview
> Support the deployment and configuration of a custom cache store.
> h2. Client Perspective
> In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server.
> h2. Implementation overview
> The implementation is based on Deployable Filters and Converters.
> Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{LoadWriteStoreRegistry}}, which will contain a list of {{AdvancedLoadWriteStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{AdvancedLoadWriteStoreFactories}} will be added after deployment scanning.
> h2. Implementation doubts and questions:
> * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}?
> * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months