[JBoss JIRA] (ISPN-6419) Drop hibernate-hql-lucene dependency, generate the lucene query directly
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-6419?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-6419:
--------------------------------
Description: The Lucene query object should be generated by visiting infinispan's AST instead of generating a jpql query string and passing it to hibernate-hql-lucene to generate the Lucene query object. This will also offer the opportunity to implement named parameters in a way that does not require query re-parsing. (was: The Lucene query object should be generated from by visiting infinispan's AST instead of generating a jpql query string and passing it to hibernate-hql-lucene to generate the Lucene query object.)
> Drop hibernate-hql-lucene dependency, generate the lucene query directly
> ------------------------------------------------------------------------
>
> Key: ISPN-6419
> URL: https://issues.jboss.org/browse/ISPN-6419
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying, Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 9.0.0.Alpha1, 9.0.0.Final
>
>
> The Lucene query object should be generated by visiting infinispan's AST instead of generating a jpql query string and passing it to hibernate-hql-lucene to generate the Lucene query object. This will also offer the opportunity to implement named parameters in a way that does not require query re-parsing.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-5123) MultiNodeDistributedTest deadlock
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5123?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes commented on ISPN-5123:
-----------------------------------------
hmm, still happening
{code}
NodeB-3992, current topology is CacheTopology{id=8, rebalanceId=4, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[MultiNodeDistributedTest-NodeB-3992: 90+37, MultiNodeDistributedTest-NodeC-12619: 81+50, MultiNodeDistributedTest-NodeD-46958: 85+54]}, pendingCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[MultiNodeDistributedTest-NodeB-3992: 80+79, MultiNodeDistributedTest-NodeC-12619: 90+90, MultiNodeDistributedTest-NodeD-46958: 86+87]}, unionCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (3)[MultiNodeDistributedTest-NodeB-3992: 90+72, MultiNodeDistributedTest-NodeC-12619: 81+100, MultiNodeDistributedTest-NodeD-46958: 85+89]}, actualMembers=[MultiNodeDistributedTest-NodeB-3992, MultiNodeDistributedTest-NodeC-12619, MultiNodeDistributedTest-NodeD-46958], persistentUUIDs=[f4b30afe-c1f3-4dee-a20f-38a5aead5e14, 88f7c6ce-a4d4-4bfc-a08d-63e6292153bf, 364b72d3-327b-45a6-9088-37b057509423]}. rebalanceInProgress=true, currentChIsBalanced=false
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:253)
at org.infinispan.test.TestingUtil.waitForRehashToComplete(TestingUtil.java:263)
at org.infinispan.query.helper.TestableCluster.waitForRehashToComplete(TestableCluster.java:62)
at org.infinispan.query.helper.TestableCluster.killNode(TestableCluster.java:57)
at org.infinispan.query.distributed.MultiNodeDistributedTest.killMasterNode(MultiNodeDistributedTest.java:79)
at org.infinispan.query.distributed.MultiNodeDistributedTest.testIndexingWorkDistribution(MultiNodeDistributedTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
{code}
> MultiNodeDistributedTest deadlock
> ---------------------------------
>
> Key: ISPN-5123
> URL: https://issues.jboss.org/browse/ISPN-5123
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Query
> Affects Versions: 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Attachments: infinispan-infinispan-query.log, stack.zip, trace.tar.gz
>
>
> I've been seeing this intermittent problem in my environment. Sometimes the query suite hangs for 30min (and then proceeds). See attached stack trace.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6522) Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-6522?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-6522:
------------------------------------
Priority: Critical (was: Major)
> Cannot use @DateBridge with WildFly modules: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6522
> URL: https://issues.jboss.org/browse/ISPN-6522
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, WildFly modules
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
> Priority: Critical
>
> The Hibernate Search engine detects if the elasticsearch backend is on the classpath,
> and if so, adds {{o.h.s.backend.elasticsearch.impl.ElasticsearchBridgeProvider}} to the top of the list of the annotation based bridge providers.
> When processing an entity with a @DateBridge annotation, it picks the elasticsearch provider to converted from/to {{Date}} objects (since it has priority) which in turn fails with the exception:
> {code}
> org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:198)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:363)
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:351)
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:93)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.convertToString(ElasticsearchBridgeProvider.java:71)
> at org.hibernate.search.backend.elasticsearch.impl.ElasticsearchBridgeProvider$EsDateBridge.set(ElasticsearchBridgeProvider.java:54)
> at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$OneWayConversionContextImpl.set(ContextualExceptionBridgeHelper.java:110)
> at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.buildDocumentFieldsForProperties(DocumentBuilderIndexedEntity.java:626)
> {code}
>
> This exception happens only when using the infinispan modules, where the elasticsearch backend is added as a dependency; in embedded mode the aforementioned provider is not loaded since the elasticsearch is not on the classpath.
> This current behaviour is not the best for two reasons:
> * When using Wildlfy modules, the elasticsearch backend is marked as optional, but still, it's visible in the classpath and gets loaded
> * If the user is not using the elasticsearch backend, but the jar is on the classpath, elasticsearch date conversion will take precedence over the built-in bridge providers, and it shouldn't
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (ISPN-6513) Inconsistencies in Maven pom files
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6513?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6513:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 9.0.0.Alpha2
9.0.0.Final
Resolution: Done
> Inconsistencies in Maven pom files
> ----------------------------------
>
> Key: ISPN-6513
> URL: https://issues.jboss.org/browse/ISPN-6513
> Project: Infinispan
> Issue Type: Task
> Affects Versions: 9.0.0.Alpha1
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Priority: Minor
> Fix For: 9.0.0.Alpha2, 9.0.0.Final
>
> Attachments: wolf_validator_results.txt
>
>
> The output of Wolf validator is attached. It reveals some bad practices and flaws in Maven pom files within the project. Let's address the most important ones.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months