October 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5825) Create Docker image for Infinispan Server

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-5825?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-5825. ----------------------------------- Fix Version/s: 8.2.3.Final Resolution: Done > Create Docker image for Infinispan Server > ----------------------------------------- > > Key: ISPN-5825 > URL: https://issues.jboss.org/browse/ISPN-5825 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: Pedro Zapata > Priority: Major > Fix For: 8.2.3.Final > > > Release a Docker image for Infinispan Server only. User can specify their own JGroups configuration file and Infinispan Cache configuration files as a startup parameter. If either configuration file is not specified, use the defaults shipped with JDG Server. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9597) Cleanup Cassandra build

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9597?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9597: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Cleanup Cassandra build > ----------------------- > > Key: ISPN-9597 > URL: https://issues.jboss.org/browse/ISPN-9597 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.1.Final > > > The cassandra cache store build needs to be updated: > - do not inherit the infinispan-persistence parent pom > - the parser should use wildcards for the versions > - add a logback.xml file to minimize logs -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8232?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8232: ---------------------------------- Status: Open (was: New) > Transaction inconsistency during network partitions > --------------------------------------------------- > > Key: ISPN-8232 > URL: https://issues.jboss.org/browse/ISPN-8232 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 9.1.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Labels: consistency > > 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.12.1#712002)

7 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8232?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8232: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6364 > Transaction inconsistency during network partitions > --------------------------------------------------- > > Key: ISPN-8232 > URL: https://issues.jboss.org/browse/ISPN-8232 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 9.1.0.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Labels: consistency > > 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.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9655) REST access log should be able to reference headers

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9655?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9655: ---------------------------------- Status: Open (was: New) > REST access log should be able to reference headers > --------------------------------------------------- > > Key: ISPN-9655 > URL: https://issues.jboss.org/browse/ISPN-9655 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 9.4.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.2.Final > > > The REST access log should be able to log request headers such as Referer and User-Agent. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9655) REST access log should be able to reference headers

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9655?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9655: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6363 > REST access log should be able to reference headers > --------------------------------------------------- > > Key: ISPN-9655 > URL: https://issues.jboss.org/browse/ISPN-9655 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 9.4.0.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.2.Final > > > The REST access log should be able to log request headers such as Referer and User-Agent. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9658) Update Documentation for Event filtering and conversion

by Lina Schad (Jira)

Lina Schad created ISPN-9658: -------------------------------- Summary: Update Documentation for Event filtering and conversion Key: ISPN-9658 URL: https://issues.jboss.org/browse/ISPN-9658 Project: Infinispan Issue Type: Bug Components: Documentation-Core Affects Versions: 9.4.0.Final Reporter: Lina Schad The part of the documentation regarding event filtering and conversion (subsection in 3.3.1) points to the KeyFilter and also contains an example that uses it. The JavaDocs mark this class as deprecated since version 9.3 and replaced by Predicate. It would be nice to have an example with the Predicate instead of the deprecated KeyFilter. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Work on ISPN-8844 started by Gustavo Fernandes. ----------------------------------------------- > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 9.4.0.Alpha1, 9.4.0.CR3, 9.3.4.Final > > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8844: ------------------------------------ Status: Pull Request Sent (was: Coding In Progress) > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 9.4.0.Alpha1, 9.4.0.CR3, 9.3.4.Final > > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8844) [JDK9+] org.infinispan.util package is exported by multiple jars

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-8844?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8844: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > [JDK9+] org.infinispan.util package is exported by multiple jars > ---------------------------------------------------------------- > > Key: ISPN-8844 > URL: https://issues.jboss.org/browse/ISPN-8844 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.6.Final > Environment: JDK9, JDK10 > Reporter: Tomaz Cerar > Assignee: Gustavo Fernandes > Priority: Major > Fix For: 9.3.4.Final, 9.4.0.CR3, 9.4.0.Alpha1 > > > Currently if you have > {{infinispan-commons-9.1.6.Final.jar}} and {{infinispan-core-9.1.6.Final.jar}} > on your module path, jvm complains as both jars export package {{org.infinispan.util}} > which violates the modules contract where only one module (jar) can provide single package. > example error that jvm prints > {noformat} > Error: Modules infinispan.commons and infinispan.core export package org.infinispan.util to module wildfly.clustering.common > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2018