[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
[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
[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
[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
[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
[JBoss JIRA] (ISPN-4229) The JDBC Cache store should not require the schema name configuration
by Ingo Maas (JIRA)
[ https://issues.jboss.org/browse/ISPN-4229?page=com.atlassian.jira.plugin.... ]
Ingo Maas commented on ISPN-4229:
---------------------------------
It is very common in production environments to have two distinct users, one to connect to the database and one for table ownership. Usually, the switch between these two users is made by using some "initSql" setting when configuring the datasource. For Oracle, the following SQL does the switch:
{code}
alter session set current_schema=TABLE_OWNER_SCHEMA
{code}
This setup fails in Infinispan's {{TableManipulation.tableExists()}}. It is wrong to assume that the connect-user retrieved by {{connection.getMetaData().getUserName()}} is equal to current database schema.
Possible ways to get current schema in Oracle are:
* use method {{javax.sql.Connection.getSchema()}}, but: introduced in JDK 7, many JDBC drivers still fail with an AbstractMethodError,
* execute SQL statement {{select sys_context('userenv', 'current_schema') from dual}}, IMHO currently the best way to go.
> The JDBC Cache store should not require the schema name configuration
> ---------------------------------------------------------------------
>
> Key: ISPN-4229
> URL: https://issues.jboss.org/browse/ISPN-4229
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Mircea Markus
>
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years