[JBoss JIRA] (ISPN-6133) Number of store misses in management console is allways 0
by Martin Vrabel (JIRA)
[ https://issues.jboss.org/browse/ISPN-6133?page=com.atlassian.jira.plugin.... ]
Martin Vrabel closed ISPN-6133.
-------------------------------
Resolution: Cannot Reproduce
> Number of store misses in management console is allways 0
> ----------------------------------------------------------
>
> Key: ISPN-6133
> URL: https://issues.jboss.org/browse/ISPN-6133
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Martin Vrabel
>
> Page: Caches -> select cache container -> select cache.
> Configuration of the cache: replicated cache, 2 nodes in the domain, eviction size=10
> In the "Cache loader" tab, there is a field "# Misses" which should show number of store misses . When I put 20 entries in the cache, first 10 will be evicted. When I try to read 10 non existing entries the cache store misses should be 10.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6175) Server throwing warning about wrong eviction configuration
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6175?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6175:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 8.2.0.Final
Resolution: Done
> Server throwing warning about wrong eviction configuration
> ----------------------------------------------------------
>
> Key: ISPN-6175
> URL: https://issues.jboss.org/browse/ISPN-6175
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction, Server
> Reporter: Martin Gencur
> Assignee: William Burns
> Priority: Minor
> Fix For: 8.2.0.CR1, 8.2.0.Final
>
>
> After building the latest ISPN snapshot (HEAD == ISPN-6137 Fix ScriptMetadataTest.testBrokenParameters), the server throws the following warning:
> ISPN000152: Passivation configured without an eviction policy being selected. Only manually evicted entities will be passivated.
> This happens whether I use default standalone.xml configuration or add eviction and passivation elements in the config. I.e. tried this config and still getting the warning:
> {code}
> <eviction strategy="LRU" size="1" type="COUNT"/>
> <file-store passivation="true" path="dc" purge="true" shared="false"/>
> {code}
> It looks like the eviction is working properly, it's just the warning that makes confusion.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6178:
--------------------------------
Description:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. Also do not use ClusterRegistry to propagate the set of classes anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0, marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
was:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
> Add ability to define indexable classes via config
> --------------------------------------------------
>
> Key: ISPN-6178
> URL: https://issues.jboss.org/browse/ISPN-6178
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Final
>
>
> Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
> This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
> Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
> 1. Introduction of a new config in indexing configuration to be able to specify the classes.
> 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
> 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. Also do not use ClusterRegistry to propagate the set of classes anymore.
> This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0, marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6178:
--------------------------------
Description:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
was:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
> Add ability to define indexable classes via config
> --------------------------------------------------
>
> Key: ISPN-6178
> URL: https://issues.jboss.org/browse/ISPN-6178
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Final
>
>
> Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
> This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. Instead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
> Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
> 1. Introduction of a new config in indexing configuration to be able to specify the classes.
> 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
> 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
> This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6178:
--------------------------------
Fix Version/s: 8.2.0.Final
> Add ability to define indexable classes via config
> --------------------------------------------------
>
> Key: ISPN-6178
> URL: https://issues.jboss.org/browse/ISPN-6178
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Final
>
>
> Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry.
> This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
> Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
> 1. Introduction of a new config in indexing configuration to be able to specify the classes.
> 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
> 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
> This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6178:
--------------------------------
Description:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
was:
Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry.
This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
1. Introduction of a new config in indexing configuration to be able to specify the classes.
2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
> Add ability to define indexable classes via config
> --------------------------------------------------
>
> Key: ISPN-6178
> URL: https://issues.jboss.org/browse/ISPN-6178
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.2.0.Final
>
>
> Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry.
> This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually).
> Given the impact of this change to existing codebase I would propose an approach that allows an easy transition:
> 1. Introduction of a new config in indexing configuration to be able to specify the classes.
> 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1.
> 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore.
> This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months