November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9494) Ickl full-text queries with wildcards are affected by upper/lower case

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9494?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes resolved ISPN-9494. ------------------------------------- Resolution: Won't Fix > Ickl full-text queries with wildcards are affected by upper/lower case > ---------------------------------------------------------------------- > > Key: ISPN-9494 > URL: https://issues.jboss.org/browse/ISPN-9494 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.2.2.Final > Reporter: Wolf-Dieter Fink > Assignee: Adrian Nistor > Priority: Major > > If an attribute is annotated with > @Field(index = Index.YES,store = Store.YES, analyze = Analyze.YES) > a full-text search with wildcards can be used like this > from proto.Person p where p.firstName : 'wolf*ng' > It is expected that the query will ignore capitalisation. So a search 'Wolf*' 'Wolf*ng' 'wolf*' should find the attribute value "Wolfgang" and "wolfgang". > But only if the query is written in lower-case it will match the expectation -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9494) Ickl full-text queries with wildcards are affected by upper/lower case

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9494?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-9494: ----------------------------------------- The full-text wildcard query is supposed to match the terms as they are stored in the index, so depending on the analyzer, it will not ignore capitalization. In the provided sample, if the firstName is "Wolfgang", given that this field is Analyzed (using the standard analyzer), it will be stored in the index as "*wolfgang*". So wolfg*ng should match, but not W*lfgang or Wolf*ng since they don't exist in the index. If the keyword analyzer were used, they the firstName would be stored in the index as "*Wolfgang*" (no analyzer), and "Wolfg*ng", Wolfgan*", etc would all match, but not "wolfgang". In general, the wildcard query should be avoided in conjunction with full-text searches, as it has a performance drawback that causes the search engine to scan for the terms rather than performing simple lookups. > Ickl full-text queries with wildcards are affected by upper/lower case > ---------------------------------------------------------------------- > > Key: ISPN-9494 > URL: https://issues.jboss.org/browse/ISPN-9494 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.2.2.Final > Reporter: Wolf-Dieter Fink > Assignee: Adrian Nistor > Priority: Major > > If an attribute is annotated with > @Field(index = Index.YES,store = Store.YES, analyze = Analyze.YES) > a full-text search with wildcards can be used like this > from proto.Person p where p.firstName : 'wolf*ng' > It is expected that the query will ignore capitalisation. So a search 'Wolf*' 'Wolf*ng' 'wolf*' should find the attribute value "Wolfgang" and "wolfgang". > But only if the query is written in lower-case it will match the expectation -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9777) Default AdvancedCacheLoader#publishEntries can hang with more than 2048 entries

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9777?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-9777: ------------------------------- Fix Version/s: 9.4.4.Final (was: 9.1.8.Final) > Default AdvancedCacheLoader#publishEntries can hang with more than 2048 entries > ------------------------------------------------------------------------------- > > Key: ISPN-9777 > URL: https://issues.jboss.org/browse/ISPN-9777 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.3.0.Final > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > The default method for AdvancedCacheLoader#publishEntries relies on the invocation of the process method. This uses the PersistenceManagerCloseableSupplier to handle this. Unfortunately it uses a WithinThreadExecutor, which actually can cause the process method to deadlock with a single thread as it can fill up the queue of 2048 elements. > We should instead use a single threaded executor which would allow the loading of elements and retrieval in parallel on 2 different threads. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9777) Default AdvancedCacheLoader#publishEntries can hang with more than 2048 entries

by Ryan Emerson (Jira)

[ https://issues.jboss.org/browse/ISPN-9777?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9777. -------------------------------- Fix Version/s: 9.1.8.Final Resolution: Done > Default AdvancedCacheLoader#publishEntries can hang with more than 2048 entries > ------------------------------------------------------------------------------- > > Key: ISPN-9777 > URL: https://issues.jboss.org/browse/ISPN-9777 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.3.0.Final > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 9.1.8.Final, 10.0.0.Alpha2 > > > The default method for AdvancedCacheLoader#publishEntries relies on the invocation of the process method. This uses the PersistenceManagerCloseableSupplier to handle this. Unfortunately it uses a WithinThreadExecutor, which actually can cause the process method to deadlock with a single thread as it can fill up the queue of 2048 elements. > We should instead use a single threaded executor which would allow the loading of elements and retrieval in parallel on 2 different threads. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9297) Prevent cache configuration that has L1 and exception based eviction

by Galder Zamarreño (Jira)

[ https://issues.jboss.org/browse/ISPN-9297?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9297: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Prevent cache configuration that has L1 and exception based eviction > -------------------------------------------------------------------- > > Key: ISPN-9297 > URL: https://issues.jboss.org/browse/ISPN-9297 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Exception based eviction is specifically around only keeping so much data in memory. There is no reason to have something like L1 in this case as it prevents using space for actual entries. It also would be quite confusing if a get caused an exception. > We should prevent this configuration from occurring. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9783) infinispan-embedded.jar 9.4.1 is failing the startup of Weblogic 12. due to missing classes

by ofer baranes (Jira)

ofer baranes created ISPN-9783: ---------------------------------- Summary: infinispan-embedded.jar 9.4.1 is failing the startup of Weblogic 12. due to missing classes Key: ISPN-9783 URL: https://issues.jboss.org/browse/ISPN-9783 Project: Infinispan Issue Type: Bug Components: Dependency Affects Versions: 9.4.1.Final Environment: Weblogic 12.1.3.0.0 Reporter: ofer baranes We have EAR file with infinispan embedded 9.4.1 jar in the lib folder of the ear. We are using ISPN for local cache. AFAIU, the embedded jar should be able in order to start, however webloic won't startup due to various errors: o Issue weblogic.management.DeploymentException: java.lang.ClassNotFoundException: org.hibernate.engine.jdbc.connections.spi.ConnectionProvider at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:123) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:260) at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) Truncated. see log file for complete stacktrace Caused By: java.lang.ClassNotFoundException: org.hibernate.engine.jdbc.connections.spi.ConnectionProvider at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:357) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:318) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:186) Truncated. see log file for complete stacktrace Analysis: com.zaxxer.hikari.hibernate.HikariConnectionProvider is importing org.hibernate.engine.jdbc.connections.spi.ConnectionProvider which is Hibernate 5 class. The embedded jar doesn't contains Hibernate5 classes and the application uses other hibernate version. Is there depenency on Hibernare5? Similiar issue: o Issue weblogic.management.DeploymentException: java.lang.ClassNotFoundException: org.conscrypt.AllocatedBuffer at weblogic.application.internal.BaseDeployment.throwAppException(BaseDeployment.java:123) at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:260) at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61) at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165) at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80) Truncated. see log file for complete stacktrace Caused By: java.lang.ClassNotFoundException: org.conscrypt.AllocatedBuffer at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:357) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:318) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:186) Truncated. see log file for complete stacktrace Again. the org.conscrypt.AllocatedBuffer class is imported by one of the netty classes but it's not part of the embedded jar. Other issue: weblogic.ejb.container.compliance.ComplianceException: Interceptor class org.infinispan.jcache.annotation.CacheResultInterceptor must have a public no-arg constructor at weblogic.ejb.container.compliance.InterceptorChecker.checkDefaultConstructorInInterceptorClass(InterceptorChecker.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at weblogic.ejb.container.compliance.EJBComplianceChecker.check(EJBComplianceChecker.java:100) at weblogic.ejb.container.compliance.EJBComplianceChecker.checkDeploymentInfo(EJBComplianceChecker.java:84) at weblogic.ejb.container.ejbc.EJBCompiler.doCompile(EJBCompiler.java:172) at weblogic.ejb.container.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:346) at weblogic.ejb.container.ejbc.EJBCompiler.compileEJB(EJBCompiler.java:314) at weblogic.ejb.container.deployer.EJBDeployer.compileJar(EJBDeployer.java:429) at weblogic.ejb.container.deployer.EJBDeployer.compileIfNecessary(EJBDeployer.java:355) at weblogic.ejb.container.deployer.EJBDeployer.prepare(EJBDeployer.java:723) at weblogic.ejb.container.deployer.EJBModule.prepare(EJBModule.java:439) at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:295) at weblogic.application.internal.ExtensibleModuleWrapper$PrepareStateChange.next(ExtensibleModuleWrapper.java:285) at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42) at weblogic.application.internal.ExtensibleModuleWrapper.prepare(ExtensibleModuleWrapper.java:109) -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9297) Prevent cache configuration that has L1 and exception based eviction

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9297?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9297: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6485, https://github.com/infinispan/infinispan/pull/6484 > Prevent cache configuration that has L1 and exception based eviction > -------------------------------------------------------------------- > > Key: ISPN-9297 > URL: https://issues.jboss.org/browse/ISPN-9297 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Exception based eviction is specifically around only keeping so much data in memory. There is no reason to have something like L1 in this case as it prevents using space for actual entries. It also would be quite confusing if a get caused an exception. > We should prevent this configuration from occurring. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9297) Prevent cache configuration that has L1 and exception based eviction

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9297?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9297: -------------------------------- Status: Open (was: New) > Prevent cache configuration that has L1 and exception based eviction > -------------------------------------------------------------------- > > Key: ISPN-9297 > URL: https://issues.jboss.org/browse/ISPN-9297 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Exception based eviction is specifically around only keeping so much data in memory. There is no reason to have something like L1 in this case as it prevents using space for actual entries. It also would be quite confusing if a get caused an exception. > We should prevent this configuration from occurring. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9297) Prevent cache configuration that has L1 and exception based eviction

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-9297?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-9297: -------------------------------- Fix Version/s: 10.0.0.Alpha2 > Prevent cache configuration that has L1 and exception based eviction > -------------------------------------------------------------------- > > Key: ISPN-9297 > URL: https://issues.jboss.org/browse/ISPN-9297 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Alpha2, 9.4.4.Final > > > Exception based eviction is specifically around only keeping so much data in memory. There is no reason to have something like L1 in this case as it prevents using space for actual entries. It also would be quite confusing if a get caused an exception. > We should prevent this configuration from occurring. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8861) DIST Iteration shouldn't go remote when a shared cache store is present

by William Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-8861?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-8861: ------------------------------------- Also this optimization wouldn't work when we have a store with write behind enabled. > DIST Iteration shouldn't go remote when a shared cache store is present > ----------------------------------------------------------------------- > > Key: ISPN-8861 > URL: https://issues.jboss.org/browse/ISPN-8861 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 9.4.4.Final > > > When a user runs a distributed iteration operation with a shared cache store, this shouldn't go remote as the local node would have all the data available to it. This is similar to the optimization when we don't go remote if the current node is an owner for all required segments. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2018