November 2018 - infinispan-issues

[JBoss JIRA] (ISPN-9706) SpringCache: get("key", Callable) not working with null values

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9706?page=com.atlassian.jira.plugin.... ] Diego Lovison updated ISPN-9706: -------------------------------- Tester: Diego Lovison > SpringCache: get("key", Callable) not working with null values > -------------------------------------------------------------- > > Key: ISPN-9706 > URL: https://issues.jboss.org/browse/ISPN-9706 > Project: Infinispan > Issue Type: Bug > Components: Spring Integration > Affects Versions: 9.4.1.Final > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 9.4.2.Final, 10.0.0.Alpha1 > > > {code:SpringCacheTest.java} > @Test > public void testGetWithNullValue() { > assertNull(cache.get("null", () -> null)); > } > {code} > {code} > Caused by: java.lang.NullPointerException: Null values are not supported! > {code} > and > {code:SpringCacheTest.java} > @Test > public void testGetNullValueAfterPutNull() { > cache.put("key", null); > String result = cache.get("key", () -> "notnull"); > assertNull(result); > } > {code} > {code} > java.lang.ClassCastException: org.infinispan.spring.provider.NullValue cannot be cast to java.lang.String > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9708) Expose threadpool executors via JMX

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9708?page=com.atlassian.jira.plugin.... ] Diego Lovison closed ISPN-9708. ------------------------------- > Expose threadpool executors via JMX > ----------------------------------- > > Key: ISPN-9708 > URL: https://issues.jboss.org/browse/ISPN-9708 > Project: Infinispan > Issue Type: Enhancement > Components: Core, JMX, reporting and management, Server > Affects Versions: 9.4.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.2.Final, 10.0.0.Alpha1 > > > We should expose executors over JMX so that threadpools can be monitored. > This includes all the global threadpools as well as any protocol server thread pools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9708) Expose threadpool executors via JMX

by Diego Lovison (Jira)

[ https://issues.jboss.org/browse/ISPN-9708?page=com.atlassian.jira.plugin.... ] Diego Lovison updated ISPN-9708: -------------------------------- Tester: Diego Lovison > Expose threadpool executors via JMX > ----------------------------------- > > Key: ISPN-9708 > URL: https://issues.jboss.org/browse/ISPN-9708 > Project: Infinispan > Issue Type: Enhancement > Components: Core, JMX, reporting and management, Server > Affects Versions: 9.4.1.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.2.Final, 10.0.0.Alpha1 > > > We should expose executors over JMX so that threadpools can be monitored. > This includes all the global threadpools as well as any protocol server thread pools. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9727) Ickle query ignores an IN clause if there is only one value

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9727?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9727: ------------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/6487, https://github.com/infinispan/infinispan/pull/6488, https://github.com/infinispan/infinispan/pull/6489 (was: https://github.com/infinispan/infinispan/pull/6487, https://github.com/infinispan/infinispan/pull/6488) > Ickle query ignores an IN clause if there is only one value > ----------------------------------------------------------- > > Key: ISPN-9727 > URL: https://issues.jboss.org/browse/ISPN-9727 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Gustavo Fernandes > Priority: Critical > Fix For: 9.3.4.Final, 10.0.0.Alpha2, 9.4.4.Final > > > If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9727) Ickle query ignores an IN clause if there is only one value

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9727?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9727: ------------------------------------ Git Pull Request: https://github.com/infinispan/infinispan/pull/6487, https://github.com/infinispan/infinispan/pull/6488 (was: https://github.com/infinispan/infinispan/pull/6487) > Ickle query ignores an IN clause if there is only one value > ----------------------------------------------------------- > > Key: ISPN-9727 > URL: https://issues.jboss.org/browse/ISPN-9727 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Gustavo Fernandes > Priority: Critical > Fix For: 9.3.4.Final, 10.0.0.Alpha2, 9.4.4.Final > > > If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9727) Ickle query ignores an IN clause if there is only one value

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9727?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9727: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/6487 > Ickle query ignores an IN clause if there is only one value > ----------------------------------------------------------- > > Key: ISPN-9727 > URL: https://issues.jboss.org/browse/ISPN-9727 > Project: Infinispan > Issue Type: Bug > Reporter: Wolf-Dieter Fink > Assignee: Gustavo Fernandes > Priority: Critical > Fix For: 9.3.4.Final, 10.0.0.Alpha2, 9.4.4.Final > > > If an Ickl query has an IN clause in combination with another condition the IN clause seems completely ignored if it has only one value. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years

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 reopened ISPN-9494: ------------------------------------- > 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
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 edited comment on ISPN-9494 at 11/30/18 4:50 AM: ------------------------------------------------------------------- The full-text wildcard query is supposed to match the terms as they are stored in the index, so 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 analysis), 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. was (Author: gustavonalle): 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 analysis), 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
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 edited comment on ISPN-9494 at 11/30/18 4:49 AM: ------------------------------------------------------------------- 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 analysis), 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. was (Author: gustavonalle): 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 analyzis), 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
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 edited comment on ISPN-9494 at 11/30/18 4:48 AM: ------------------------------------------------------------------- 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 analyzis), 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. was (Author: gustavonalle): 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
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2018