August 2020 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-12184) Implicit authentication config stomps on explicit config

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-12184: -------------------------------------- Summary: Implicit authentication config stomps on explicit config Key: ISPN-12184 URL: https://issues.redhat.com/browse/ISPN-12184 Project: Infinispan Issue Type: Bug Components: Configuration, Server Affects Versions: 12.0.0.Dev01 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 12.0.0.Dev02 The server overwrites any explicit security configuration set on the individual protocols, including realm and mechanisms. If these are set explicitly, they should be respected. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12183) Transaction inconsistency during network partitions

by Wolf-Dieter Fink (Jira)

Wolf-Dieter Fink created ISPN-12183: --------------------------------------- Summary: Transaction inconsistency during network partitions Key: ISPN-12183 URL: https://issues.redhat.com/browse/ISPN-12183 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 9.1.0.Final Reporter: Wolf-Dieter Fink Assignee: Pedro Ruivo In scenario where the originator stays in minor partition (in our test suite, the originator isolated tests), it is possible to a transaction to be committed and rolled back in the majority partition. In {{Pessimitic Locking}}, the transaction is committed in one-phase using the {{PrepareCommand}}. If the partition happens when the originator sends the {{PrepareCommand}}, the nodes in the majority partition may or may not receive it. We can have the case where some nodes receive the {{PrepareCommand}} and applied and other don't receive it. When the topology is updated in the majority partition, the {{TransactionTable}} rollbacks all transaction in which the originator isn't present. So, in the nodes where the {{PrepareCommand}} isn't received, the transaction is rolled back. The originator in the minory partition detects the partition and marks the transaction partially completed. When the merge occurs, it tries to commit the transaction again. In the nodes where the transaction is rolled back, the transaction is marked as completed and when the {{PrepareCommand}} is received, it throws an {{IllegalStateException}} ({{TransactionTable:386, getOrCreateRemoteTransaction()}}). In this case, the transaction isn't removed from the {{PartitionHandlingManager}} and our test suite fails with {{"there are pending tx".}} Other theoretically scenario is the {{PrepareCommand}} to be executed when no locks are acquired. The same issue can happen with {{Optimistic Locking}} for the {{CommitCommand}}. The problem is the transaction table can't identify is the node left gracefully or not. A solution would be to have an {{"expected members"}} list, ideally separated from the {{CacheTopology}} to avoid sending it every time. Also, it would need some sysadmin tools for the case where the node crashes and it won't be back online for a while (or for some reason, it doesn't need to be back online). A sysadmin could remove the node from this list ({{CacheTopology}} is updated and there is no need to increase it) and decide what to do with the pending transactions (or an automatic mechanism to auto-commit/rollback the transaction). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11965) Assume protostream format for server caches

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11965?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11965: ------------------------------------- Description: Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that uses the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, and since the HR client uses protostream by default, server caches should also use it. The side effect is clients using anything else other than protostream would need to specifically configure the marshalled format in the server (was: Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that would use the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, ) > Assume protostream format for server caches > ------------------------------------------- > > Key: ISPN-11965 > URL: https://issues.redhat.com/browse/ISPN-11965 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > > Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that uses the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, and since the HR client uses protostream by default, server caches should also use it. The side effect is clients using anything else other than protostream would need to specifically configure the marshalled format in the server -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11965) Assume protostream format for server caches

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11965?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11965: ------------------------------------- Summary: Assume protostream format for server caches (was: Prevent conversions in caches with unknown formats) > Assume protostream format for server caches > ------------------------------------------- > > Key: ISPN-11965 > URL: https://issues.redhat.com/browse/ISPN-11965 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > > Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that would use the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-11965) Prevent conversions in caches with unknown formats

by Gustavo Fernandes (Jira)

[ https://issues.redhat.com/browse/ISPN-11965?page=com.atlassian.jira.plugi... ] Gustavo Fernandes updated ISPN-11965: ------------------------------------- Description: Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that would use the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, (was: Usages of filter/converters, remote iterators, listeners, scripts, REST and everything that could involve transcoder should throw an error if the cache doesn't have an encoding.More specifically, APPLICATION_UNKNOW should not be handled by any transcoder) > Prevent conversions in caches with unknown formats > -------------------------------------------------- > > Key: ISPN-11965 > URL: https://issues.redhat.com/browse/ISPN-11965 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Final > > > Caches that does not specify any MediaType are assumed to have an special media type APPLICATION_UNKNOW that would use the configured marshaller in the server. Embedded caches are already assumed to have application/x-java-object encoding, -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12182) Support for scroll on search

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-12182: ---------------------------------------- Summary: Support for scroll on search Key: ISPN-12182 URL: https://issues.redhat.com/browse/ISPN-12182 Project: Infinispan Issue Type: Enhancement Components: Embedded Querying Reporter: Gustavo Fernandes -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-12178) Query broadcast blocks on the non-blocking executor

by Will Burns (Jira)

[ https://issues.redhat.com/browse/ISPN-12178?page=com.atlassian.jira.plugi... ] Will Burns updated ISPN-12178: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 12.0.0.Dev02 Resolution: Done > Query broadcast blocks on the non-blocking executor > ---------------------------------------------------- > > Key: ISPN-12178 > URL: https://issues.redhat.com/browse/ISPN-12178 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 12.0.0.Dev01 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 12.0.0.Dev02 > > > {noformat} > java.lang.AssertionError: Blocking call! java.io.RandomAccessFile#readBytes on thread Thread[non-blocking-thread-CacheV2ResourceTest-NodeA-p13-t6,5,ISPN-non-blocking-thread-group] > at org.hibernate.search.backend.lucene.index.impl.LuceneIndexManagerImpl.openIndexReaders(LuceneIndexManagerImpl.java:153) > at org.hibernate.search.backend.lucene.lowlevel.reader.impl.HibernateSearchMultiReader.open(HibernateSearchMultiReader.java:50) > at org.hibernate.search.backend.lucene.orchestration.impl.LuceneSyncWorkOrchestratorImpl$WorkExecution.<init>(LuceneSyncWorkOrchestratorImpl.java:107) > at org.hibernate.search.backend.lucene.orchestration.impl.LuceneSyncWorkOrchestratorImpl.submit(LuceneSyncWorkOrchestratorImpl.java:47) > at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.doSubmit(LuceneSearchQueryImpl.java:146) > at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.fetch(LuceneSearchQueryImpl.java:93) > at org.hibernate.search.backend.lucene.search.query.impl.LuceneSearchQueryImpl.fetch(LuceneSearchQueryImpl.java:35) > at org.hibernate.search.engine.search.query.spi.AbstractSearchQuery.fetchAll(AbstractSearchQuery.java:35) > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.collectKeys(CQCreateEagerQuery.java:33) > at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:25) > at org.infinispan.query.clustered.commandworkers.CQCommandType.perform(CQCommandType.java:44) > at org.infinispan.query.clustered.ClusteredQueryOperation.perform(ClusteredQueryOperation.java:54) > at org.infinispan.query.clustered.SegmentsClusteredQueryCommand.perform(SegmentsClusteredQueryCommand.java:45) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 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