[JBoss JIRA] (ISPN-12102) Validate configuration before storing it
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12102?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12102:
--------------------------------
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Dev03)
> Validate configuration before storing it
> ----------------------------------------
>
> Key: ISPN-12102
> URL: https://issues.redhat.com/browse/ISPN-12102
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.1.Final
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> Although {{ConfigurationBuilder}} does some validation, sometimes it needs something more. As an example, the cross-site replication needs a running {{Transport}} to check if xsite is really supported.
> As a side effect, the console is broken when you try to define the following cache without {{RELAY2}} being present in the JGroups stack.
> {code:xml}
> <infinispan>
> <cache-container>
> <distributed-cache name="xsite">
> <backups>
> <backup site="site2"/>
> </backups>
> </distributed-cache>
> </cache-container>
> </infinispan>
> {code}
> This happens because the {{Configuration}} is stored and the {{Cache}} with the exception is stored as well.
> The fix proposed it adds a method to {{ModuleLifecyle}} where the {{Configuration}} can be validated before it is store in the "global state".
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12273) Potential race condition during wiring of EncoderCache
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12273?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12273:
--------------------------------
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Dev03)
> Potential race condition during wiring of EncoderCache
> ------------------------------------------------------
>
> Key: ISPN-12273
> URL: https://issues.redhat.com/browse/ISPN-12273
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.3.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 11.0.4.Final, 12.0.0.Dev04
>
>
> Since the upgrade to 11.0.x, we have encountered intermittent cache startup failures in WildFly that look to be due to a race condition in the wiring of the EncoderCache. Unfortunately, I have been unable to reproduce the issue locally. Here is a sample stack trace demonstrating the issue taken from the CI:
> {noformat}
> [31m08:41:33,153 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 18) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache.web.default-server: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache.web.default-server: org.infinispan.commons.CacheConfigurationException: Component org.infinispan.factories.EncoderRegistryFactory is missing a strong reference: waiting to become INSTANTIATED but it has not been instantiated yet
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:66)
> at org.wildfly.clustering.service.AsyncServiceConfigurator$AsyncService.lambda$start$0(AsyncServiceConfigurator.java:117)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1990)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:513)
> Caused by: org.infinispan.commons.CacheConfigurationException: Component org.infinispan.factories.EncoderRegistryFactory is missing a strong reference: waiting to become INSTANTIATED but it has not been instantiated yet
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.awaitWrapperState(BasicComponentRegistryImpl.java:692)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:150)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent(BasicComponentRegistryImpl.java:65)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.findFactory(BasicComponentRegistryImpl.java:257)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:132)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent(BasicComponentRegistryImpl.java:65)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:125)
> at org.infinispan.factories.impl.WireContext.get(WireContext.java:20)
> at org.infinispan.encoding.impl.CorePackageImpl$1.wire(CorePackageImpl.java:30)
> at org.infinispan.encoding.impl.CorePackageImpl$1.wire(CorePackageImpl.java:27)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:339)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.doWireWrapper(BasicComponentRegistryImpl.java:236)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:217)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.getComponent0(BasicComponentRegistryImpl.java:152)
> at org.infinispan.factories.impl.WireContext.get(WireContext.java:20)
> at org.infinispan.encoding.CorePackageImpl$1.wire(CorePackageImpl.java:30)
> at org.infinispan.encoding.CorePackageImpl$1.wire(CorePackageImpl.java:27)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:339)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireDependencies(BasicComponentRegistryImpl.java:247)
> at org.infinispan.cache.impl.EncoderCache.wireRealCache(EncoderCache.java:120)
> at org.infinispan.cache.impl.CorePackageImpl$4.wire(CorePackageImpl.java:92)
> at org.infinispan.cache.impl.CorePackageImpl$4.wire(CorePackageImpl.java:88)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.invokeInjection(BasicComponentRegistryImpl.java:339)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.doWireWrapper(BasicComponentRegistryImpl.java:236)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.wireWrapper(BasicComponentRegistryImpl.java:217)
> at org.infinispan.factories.impl.BasicComponentRegistryImpl.registerComponent(BasicComponentRegistryImpl.java:376)
> at org.infinispan.factories.InternalCacheFactory.bootstrap(InternalCacheFactory.java:170)
> at org.infinispan.factories.InternalCacheFactory.createAndWire(InternalCacheFactory.java:116)
> at org.infinispan.factories.InternalCacheFactory.createCache(InternalCacheFactory.java:84)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:687)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:643)
> at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:532)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:510)
> at org.jboss.as.clustering.infinispan.DefaultCacheContainer.getCache(DefaultCacheContainer.java:92)
> at org.wildfly.clustering.infinispan.spi.service.CacheServiceConfigurator.get(CacheServiceConfigurator.java:77)
> at org.wildfly.clustering.infinispan.spi.service.CacheServiceConfigurator.get(CacheServiceConfigurator.java:55)
> at org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:63)
> ... 7 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12279) Default value of @IndexedEmbedded.depth is not correctly interpreted
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12279?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12279:
--------------------------------
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Dev03)
> Default value of @IndexedEmbedded.depth is not correctly interpreted
> --------------------------------------------------------------------
>
> Key: ISPN-12279
> URL: https://issues.redhat.com/browse/ISPN-12279
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying
> Affects Versions: 12.0.0.Dev02
> Reporter: Yoann Rodière
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> There was a problem during the migration to Search 6, and the processor for the annotation {{@IndexedEmbedded}} apparently does not correctly intepret {{@IndexedEmbedded()}} as "no depth defined".
> As a result, {{@IndexedEmbedded(includePaths = { "foo" })}} will not set the depth to 0 as it should, but to {{Integer.MAX_VALUE}} (the default defined on the {{(a)IndexedEmbedded.depth()}} attribute) and will end up incorrectly including the whole embedded document.
> The code to change is this (in {{org.hibernate.search.annotations.IndexedEmbedded}}):
> {code}
> Integer cleanedUpMaxDepth = annotation.depth();
> if ( cleanedUpMaxDepth.equals( -1 ) ) {
> cleanedUpMaxDepth = null;
> }
> {code}
> It should be instead:
> {code}
> Integer cleanedUpMaxDepth = annotation.depth();
> if ( cleanedUpMaxDepth.equals( Integer.MAX_VALUE ) ) {
> cleanedUpMaxDepth = null;
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12288) Upgrade to Hibernate Search 6.0.0.Beta10
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12288?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12288:
--------------------------------
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Dev03)
> Upgrade to Hibernate Search 6.0.0.Beta10
> ----------------------------------------
>
> Key: ISPN-12288
> URL: https://issues.redhat.com/browse/ISPN-12288
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 12.0.0.Dev02
> Reporter: Yoann Rodière
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 12.0.0.Dev04
>
> Attachments: javabean-property-access.diff
>
>
> https://in.relation.to/2020/09/07/hibernate-search-6-0-0-Beta10/
> Relevant changes:
> * {{maxDepth}} was renamed to {{includeDepth}}; this may affect the mapping code for Remote Query in particular. PR: https://github.com/hibernate/hibernate-search/pull/2337
> * If Infinispan calls {{SearchResult#totalHitCount()}} anywhere, then it should now call {{total().hitCount()}} instead. {{totalHitCount}} is deprecated.
> * Some SPI interfaces related to the type model have changed and Infinispan implementation may not compile anymore. I recommend changing the Infinispan implementation the same way we changed another mapper bundled with Search (see the attached diff). An added benefit: with these changes, embedded mode will support annotations on both methods and fields (which was supported in 5 but was dropped during the migration to Search 6).
> * {{IndexFieldDescriptor}} now exposes a {{multiValuedInRoot()}} method, which I was told would be very useful to Infinispan, which currently has to go through some hoops to compute that value based on the multi-valued-ness of a field **and its parents**.
> * Timeouts are now forwarded to the entity loader. If Infinispan defines an entity loader when loading hits as entities instead of projections (and it probably should), some changes may be necessary in this area. PR: https://github.com/hibernate/hibernate-search/pull/2333
> Optionally, the new ["total hit count threshold"|https://in.relation.to/2020/09/07/hibernate-search-6-0-0-Beta10/#total-hit-count-threshold] could be used to improve performance in Infinispan, but that should probably be addressed a follow-up ticket.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months
[JBoss JIRA] (ISPN-12275) Restore support for @Field(analyzer = ...) and @Field(normalizer = ...)
by Katia Aresti (Jira)
[ https://issues.redhat.com/browse/ISPN-12275?page=com.atlassian.jira.plugi... ]
Katia Aresti updated ISPN-12275:
--------------------------------
Fix Version/s: 12.0.0.Dev04
(was: 12.0.0.Dev03)
> Restore support for @Field(analyzer = ...) and @Field(normalizer = ...)
> -----------------------------------------------------------------------
>
> Key: ISPN-12275
> URL: https://issues.redhat.com/browse/ISPN-12275
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying
> Reporter: Yoann Rodière
> Priority: Major
> Fix For: 12.0.0.Dev04
>
>
> In Infinispan 11 (Hibernate Search 5.10/5.11), it used to be possible to assign an analyzer or normalizer to a field with the following syntax:
> {code}
> @Field(analyzer = @Analyzer(definition = "myAnalyzer"))
> private String myProperty;
> @Field(analyzer = @Normalizer(definition = "myNormalizer"))
> private String myProperty;
> {code}
> It seems that we made a mistake during the upgrade to Search 6, and support for this syntax was removed. All that's left is the property-scoped syntax, where the analyzer is defined next to the field:
> {code}
> @Field
> @Analyzer(definition = "myAnalyzer")
> private String myProperty;
> {code}
> If we want to provide at least partial backward compatibility in annotations, we should restore support for the former syntax (and keep the latter).
> For the record, analyzer assigned using the former syntax take precedence over analyzers assigned using the latter.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 9 months