[jboss-jira] [JBoss JIRA] (WFLY-5539) Infinispan subsystem attributes are not persisted

[Michal Karm Babacek (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-5539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13119445#comment-13119445 ] 

Michal Karm Babacek edited comment on WFLY-5539 at 10/19/15 9:15 AM:
---------------------------------------------------------------------

[~pferraro] Thanks for the link Paul. I wonder that even if I get rid of Lucene search and go with Infinispan DSL Queries, which would mean translating from, e.g.
{code}
SearchManager searchManager = org.infinispan.query.Search.getSearchManager(myTestCache);
QueryBuilder queryBuilder = searchManager.buildQueryBuilderForClass(TestIndexedPojo.class).get();
Query luceneQuery = queryBuilder
    .bool()
    .must(queryBuilder.range().onField("start").below(value).createQuery())
    .must(queryBuilder.range().onField("end").above(value).createQuery())
    .createQuery();
CacheQuery query = searchManager.getQuery(luceneQuery, TestIndexedPojo.class);
{code}
to
{code}
QueryFactory qf = Search.getQueryFactory(myTestCache);
Query query = qf.from(TestIndexedPojo.class)
    .having("start").lte(value)
    .and()
    .having("end").gte(value)
    .toBuilder().build();
{code}
I would still like to have indexing enabled on the cache.

If I add *infinispan-query* module to the Infinispan subsystem {{modules/system/layers/base/org/infinispan/}} and declare a dependency on it in my EAR's {{META-INF/MANIFEST.MF}}, would I be able to switch indexing on on a cache defined within the Infinispan subsystem?

On the other hand, I cannot resist a feeling that this is rather dirty, fiddling with Wildfly's subsystem.
Isn't there a way that would allow one to supply infinispan-query within one's deployment and thus enable one's application to switch indexing on on a cache programatically at runtime? Which implies changing a configuration of a cache defined in {{standalone-ha.xml}} and managed by the application server...I feel like I'm running in a circle.
Thanks for any comments.


was (Author: mbabacek):
[~pferraro] Thanks for the link Paul. I wonder that even if I get rid of Lucene search and go with Infinispan DSL Queries, which would mean translating from, e.g.
{code}
SearchManager searchManager = org.infinispan.query.Search.getSearchManager(myTestCache);
QueryBuilder queryBuilder = searchManager.buildQueryBuilderForClass(TestIndexedPojo.class).get();
Query luceneQuery = queryBuilder
    .bool()
    .must(queryBuilder.range().onField("start").below(value).createQuery())
    .must(queryBuilder.range().onField("end").above(value).createQuery())
    .createQuery();
CacheQuery query = searchManager.getQuery(luceneQuery, TestIndexedPojo.class);
{code}
to
{code}
QueryFactory qf = Search.getQueryFactory(myTestCache);
Query query = qf.from(TestIndexedPojo.class)
    .having("start").lte(value)
    .and()
    .having("end").gte(value)
    .toBuilder().build();
{code}
I would still like to have indexing enabled on the cache.

If I add *infinispan-query* module to the Infinispan subsystem {{modules/system/layers/base/org/infinispan/}} and declare a dependency on it in my EAR's {META-INF/MANIFEST.MF}, would I be able to switch indexing on on a cache defined within the Infinispan subsystem?

On the other hand, I cannot resist a feeling that this is rather dirty, fiddling with Wildfly's subsystem.
Isn't there a way that would allow one to supply infinispan-query within one's deployment and thus enable one's application to switch indexing on on a cache programatically at runtime? Which implies changing a configuration of a cache defined in {{standalone-ha.xml}} and managed by the application server...I feel like I'm running in a circle.
Thanks for any comments.

> Infinispan subsystem attributes are not persisted
> -------------------------------------------------
>
>                 Key: WFLY-5539
>                 URL: https://issues.jboss.org/browse/WFLY-5539
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 10.0.0.CR2
>            Reporter: Michal Karm Babacek
>            Assignee: Paul Ferraro
>            Priority: Critical
>             Fix For: 10.0.0.CR3
>
>
> Certain cache configuration attributes are not persisted after reload. I find this issue being a critical one because if effectively prevents me from enabling indexing on my custom caches.
> For instance, there are no attributes *indexing* nor *batching* in the [jboss-as-infinispan_4_0.xsd|https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/resources/schema/jboss-as-infinispan_4_0.xsd], whereas CLI allows one to set these; nonetheless in vain, because the values are not persisted.
> {noformat}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching)
> {
>     "outcome" => "success",
>     "result" => false
> }
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing)
> {
>     "outcome" => "success",
>     "result" => "NONE"
> }
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=indexing,value=ALL)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:write-attribute(name=batching,value=true)
> {
>     "outcome" => "success",
>     "response-headers" => {
>         "operation-requires-reload" => true,
>         "process-state" => "reload-required"
>     }
> }
> [standalone at localhost:9990 /] reload
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=indexing)
> {
>     "outcome" => "success",
>     "result" => "NONE"
> }
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=server/replicated-cache=BLACKLIST_CACHE:read-attribute(name=batching)
> {
>     "outcome" => "success",
>     "result" => false
> }
> {noformat}
> Is there any other way how one could enable indexing on one's cache? E.g. my cache:
> {code}
> <replicated-cache name="BLACKLIST_CACHE" mode="ASYNC">
>     <locking acquire-timeout="60000" concurrency-level="3000" isolation="REPEATABLE_READ"/>
>     <transaction mode="NONE"/>
>     <eviction max-entries="10000000" strategy="NONE"/>
>     <expiration interval="-1" lifespan="-1" max-idle="-1"/>
>     <file-store/>
>     <state-transfer timeout="300000"/>
> </replicated-cache>
> {code} Obviously, adding aforementioned attributes to the cache element results in an XML parsing error...
> Last but not least, is there any way how to circumvent the bug and force indexing so as to avoid deadly exceptions such as: {noformat}java.lang.IllegalArgumentException: Indexing was not enabled on this cache. interface org.hibernate.search.spi.SearchIntegrator not found in registry{noformat}? I'm very well aware of the possibility to configure the whole cache programatically in runtime using CacheManager -- but that is the very situation I was trying to migrate away from.
> Thx for comments.
>  



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)