August 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-11873) Add report failure for RxJava Undelivered Errors

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11873?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11873: ------------------------------- Fix Version/s: 11.0.4.Final (was: 11.0.3.Final) > Add report failure for RxJava Undelivered Errors > ------------------------------------------------ > > Key: ISPN-11873 > URL: https://issues.redhat.com/browse/ISPN-11873 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 11.0.4.Final > > > We should install an error handler into RxJava during the test suite so that if we get any undelivered exceptions they will be reported, similar to uncaught exception handler that was added. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11851) FD_SOCK should use the same bind address as TCP

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11851?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11851: ------------------------------- Fix Version/s: 11.0.4.Final (was: 11.0.3.Final) > FD_SOCK should use the same bind address as TCP > ----------------------------------------------- > > Key: ISPN-11851 > URL: https://issues.redhat.com/browse/ISPN-11851 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.0.Dev05, 10.1.8.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.4.Final > > > In the JGroups configuration files we ship, we use a different default for {{TCP.bind_addr}} and {{UDP.bind_addr}} than JGroups does. > {code:xml} > <TCP bind_addr="${jgroups.bind.address,jgroups.tcp.address:SITE_LOCAL}"/> > <UDP bind_addr="${jgroups.bind.address,jgroups.udp.address:SITE_LOCAL}"/> > {code} > However, we didn't change the default for {{FD_SOCK}}, so it uses the JGroups default: -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11585) Use JavaSerializationMarshaller in jcache TCK modules

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-11585?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-11585: ------------------------------- Fix Version/s: 11.0.4.Final (was: 11.0.3.Final) > Use JavaSerializationMarshaller in jcache TCK modules > ----------------------------------------------------- > > Key: ISPN-11585 > URL: https://issues.redhat.com/browse/ISPN-11585 > Project: Infinispan > Issue Type: Task > Components: JCache > Affects Versions: 11.0.0.Dev03 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 11.0.4.Final > > > We should run the JSR-107 TCK with the java serialization marshaller, not with the protostream marshaller, to ensure that Infinispan is usable as a JCache implementation with minimal application code changes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12029: ------------------------------- Fix Version/s: 11.0.4.Final (was: 11.0.3.Final) > Replace Blocking Executor with an EnhancedQueueExecutor > ------------------------------------------------------- > > Key: ISPN-12029 > URL: https://issues.redhat.com/browse/ISPN-12029 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Will Burns > Assignee: Will Burns > Priority: Major > Fix For: 12.0.0.Final, 11.0.4.Final > > > The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread. > > The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12015) NPE if DefaultCacheManager created with InputStream and `xi:include` required

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12015?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12015: ------------------------------- Fix Version/s: 11.0.4.Final (was: 11.0.3.Final) > NPE if DefaultCacheManager created with InputStream and `xi:include` required > ----------------------------------------------------------------------------- > > Key: ISPN-12015 > URL: https://issues.redhat.com/browse/ISPN-12015 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Core > Affects Versions: 11.0.0.Final > Reporter: Ryan Emerson > Assignee: Tristan Tarrant > Priority: Major > Fix For: 11.0.4.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12186) Upgrade to Hibernate Search 6.0.0.Beta9

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12186?page=com.atlassian.jira.plugi... ] Work on ISPN-12186 started by Gustavo Fernandes. ------------------------------------------------ > Upgrade to Hibernate Search 6.0.0.Beta9 > --------------------------------------- > > Key: ISPN-12186 > URL: https://issues.redhat.com/browse/ISPN-12186 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Reporter: Yoann Rodière > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Dev02 > > > TODO: > * Upgrade the Hibernate Search dependency (obviously); be warned the Lucene dependency is now 8.6.0 > * Handle [deprecations and breaking changes|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#breaking_changes] > * Simplify the configuration properties generated by Infinispan and passed to Hibernate Search; see [here|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#simpler-configuration-scheme]. > * Simplify the generation of IDs: {{org.hibernate.search.mapper.pojo.work.spi.PojoIndexer}} now allows passing the routing key explicitly (in our case, {{String.valueOf(segmentId)}}), so our custom implementation of {{RoutingKeyBridge}} (which relies on a hack) is no longer necessary. > * As a result of the previous item, we can also get rid of the hack that concatenates the segment ID to the document ID; see ISPN-12170. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12186) Upgrade to Hibernate Search 6.0.0.Beta9

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12186?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-12186: ------------------------------------- Status: Open (was: New) > Upgrade to Hibernate Search 6.0.0.Beta9 > --------------------------------------- > > Key: ISPN-12186 > URL: https://issues.redhat.com/browse/ISPN-12186 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Reporter: Yoann Rodière > Priority: Major > Fix For: 12.0.0.Dev02 > > > TODO: > * Upgrade the Hibernate Search dependency (obviously); be warned the Lucene dependency is now 8.6.0 > * Handle [deprecations and breaking changes|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#breaking_changes] > * Simplify the configuration properties generated by Infinispan and passed to Hibernate Search; see [here|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#simpler-configuration-scheme]. > * Simplify the generation of IDs: {{org.hibernate.search.mapper.pojo.work.spi.PojoIndexer}} now allows passing the routing key explicitly (in our case, {{String.valueOf(segmentId)}}), so our custom implementation of {{RoutingKeyBridge}} (which relies on a hack) is no longer necessary. > * As a result of the previous item, we can also get rid of the hack that concatenates the segment ID to the document ID; see ISPN-12170. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12186) Upgrade to Hibernate Search 6.0.0.Beta9

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-12186?page=com.atlassian.jira.plugi... ] Gustavo Fernandes reassigned ISPN-12186: ---------------------------------------- Assignee: Gustavo Fernandes > Upgrade to Hibernate Search 6.0.0.Beta9 > --------------------------------------- > > Key: ISPN-12186 > URL: https://issues.redhat.com/browse/ISPN-12186 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Reporter: Yoann Rodière > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Dev02 > > > TODO: > * Upgrade the Hibernate Search dependency (obviously); be warned the Lucene dependency is now 8.6.0 > * Handle [deprecations and breaking changes|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#breaking_changes] > * Simplify the configuration properties generated by Infinispan and passed to Hibernate Search; see [here|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#simpler-configuration-scheme]. > * Simplify the generation of IDs: {{org.hibernate.search.mapper.pojo.work.spi.PojoIndexer}} now allows passing the routing key explicitly (in our case, {{String.valueOf(segmentId)}}), so our custom implementation of {{RoutingKeyBridge}} (which relies on a hack) is no longer necessary. > * As a result of the previous item, we can also get rid of the hack that concatenates the segment ID to the document ID; see ISPN-12170. > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12097) Invalidation Cache with a shared store doesn't work properly after new SPI changes

by Pedro Ruivo (Jira)

[ https://issues.redhat.com/browse/ISPN-12097?page=com.atlassian.jira.plugi... ] Pedro Ruivo updated ISPN-12097: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Dev02 Resolution: Done > Invalidation Cache with a shared store doesn't work properly after new SPI changes > ---------------------------------------------------------------------------------- > > Key: ISPN-12097 > URL: https://issues.redhat.com/browse/ISPN-12097 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores > Affects Versions: 11.0.1.Final > Reporter: Paul Ferraro > Assignee: Will Burns > Priority: Blocker > Fix For: 12.0.0.Final, 12.0.0.Dev02, 11.0.3.Final > > Attachments: Test.java > > > There seems to be something amiss with the new NonBlockingStore changes. When a transactional invalidation cache is used with a shared cache store, I've observed the entries published to the removePublisher of the NonBlockStore.batch(...) which should have targeted the writePublisher. This seems to happen when a batch only contains writes, but no removes. > See the attached test to reproduce the issue, which executes two simple cache operations against a transactional vs non-transactional cache using a shared write-through store. The transactional version fails due to unexpected removals triggered by the batch(...) method (which, in the case of the JDBC store delegates to the deleteBatch(...) and bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published to the removePublisher of batch(...) when transactions are enabled causing entries to be removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are disabled, the batch(...) method is, of course, not in play, and everything works correctly via the individual write/delete methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12202) Invalidation Cache with a shared store doesn't work properly after new SPI changes

by Pedro Ruivo (Jira)

Pedro Ruivo created ISPN-12202: ---------------------------------- Summary: Invalidation Cache with a shared store doesn't work properly after new SPI changes Key: ISPN-12202 URL: https://issues.redhat.com/browse/ISPN-12202 Project: Infinispan Issue Type: Bug Components: Core, Loaders and Stores Affects Versions: 11.0.1.Final Reporter: Paul Ferraro Assignee: Will Burns Fix For: 12.0.0.Final, 11.0.3.Final There seems to be something amiss with the new NonBlockingStore changes. When a transactional invalidation cache is used with a shared cache store, I've observed the entries published to the removePublisher of the NonBlockStore.batch(...) which should have targeted the writePublisher. This seems to happen when a batch only contains writes, but no removes. See the attached test to reproduce the issue, which executes two simple cache operations against a transactional vs non-transactional cache using a shared write-through store. The transactional version fails due to unexpected removals triggered by the batch(...) method (which, in the case of the JDBC store delegates to the deleteBatch(...) and bulkUpdate(...) methods. TRACE logging indicates that entries are unexpectedly published to the removePublisher of batch(...) when transactions are enabled causing entries to be removed unexpectedly from the store (as the result of a Cache.put(...)). When tx are disabled, the batch(...) method is, of course, not in play, and everything works correctly via the individual write/delete methods. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2020