September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3518) 1PC can cause a window of inconsistency with L1 invalidation

by William Burns (JIRA)

William Burns created ISPN-3518: ----------------------------------- Summary: 1PC can cause a window of inconsistency with L1 invalidation Key: ISPN-3518 URL: https://issues.jboss.org/browse/ISPN-3518 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: William Burns Assignee: Mircea Markus The L1TxInterceptor currently doesn't block on L1 invalidations during a 1PC. This can cause an inconsistent view of data across non owner nodes. Example: {quote} Node A owns k with value of v1 Node B has k in L1 with value of v1 tx1 started Node A put k -> v2 Node A sends invalidation Node A commits tx1 completed tx2 started Node B get k returns v1 from L1 tx2 completed Node B gets invalidation for k tx2 started Node B get k remotely retrieves v2 from Node A tx2 completed {quote} We need to make sure that all L1 invalidations in Tx mode are completed before completing the transaction. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2177) Refactor AbstractCacheTransaction

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2177?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2177: -------------------------------- Issue Type: Bug (was: Feature Request) > Refactor AbstractCacheTransaction > ----------------------------------- > > Key: ISPN-2177 > URL: https://issues.jboss.org/browse/ISPN-2177 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.1.2.FINAL > Reporter: Mircea Markus > Assignee: William Burns > Labels: refactoring, transaction > Fix For: 6.0.0.CR1 > > > There are several collections holding transaction related information in the AbstractCacheTransaction: > - lockedKeys: this holds all the keys that were actually locked on the local node > - affectedKeys: this holds all the keys that were acquired by the transaction allover the cluster > - backupKeyLocks: this holds all the locks for which the local node is a secondary data owner. > To do: > - affectedKeys belongs to LocalCacheTransaction(subclass) and no point in having it in the AbstractCacheTransaction > - a better name for affectedKeys might be "clusterLockedKey" and for lockedKeys --> localLokedKeys > - also add a Javadoc explaining the correlation between these key groups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3501) Upgrade JGroups to 3.4.0.Alpha3

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3501?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3501: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade JGroups to 3.4.0.Alpha3 > ------------------------------- > > Key: ISPN-3501 > URL: https://issues.jboss.org/browse/ISPN-3501 > Project: Infinispan > Issue Type: Component Upgrade > Affects Versions: 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3499) Resource leak in HotRod Server when unable to start

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3499?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3499: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Resource leak in HotRod Server when unable to start > --------------------------------------------------- > > Key: ISPN-3499 > URL: https://issues.jboss.org/browse/ISPN-3499 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > the HotRod server does not unbind the address:port if some exception happens during the start process. > This is making the test suite failing: http://ci.infinispan.org/viewLog.html?buildId=3157&tab=buildResultsDiv&bu... > One possible solution to deal is to catch all the exceptions in the start process and invoke the stop to make the server to unbind and close the socket in that particular address:port. > Other solution is to make the user responsible to catch and stop the server. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3510) Infinispan 6.0 should be able to parse 5.2.x config files and use 5.2.x custom cache stores

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3510?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3510: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-server/pull/150 > Infinispan 6.0 should be able to parse 5.2.x config files and use 5.2.x custom cache stores > -------------------------------------------------------------------------------------------- > > Key: ISPN-3510 > URL: https://issues.jboss.org/browse/ISPN-3510 > Project: Infinispan > Issue Type: Feature Request > Affects Versions: 6.0.0.Alpha4 > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 6.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3502) GridFile.isChildOf() incorrectly compares file paths.

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3502?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3502: ------------------------------ Issue Type: Bug (was: Feature Request) > GridFile.isChildOf() incorrectly compares file paths. > ----------------------------------------------------- > > Key: ISPN-3502 > URL: https://issues.jboss.org/browse/ISPN-3502 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 5.2.6.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Fix For: 6.0.0.Beta1 > > > This is the method in GridFile that is executed to compare paths. However, it doesn't compare the parent with a trailing `File.separator`, so all children with a path that starts with the parent path (even without a File.separator) are considered children. > E.g: > {code} > src/main/java > src/main/java-NOT-A-CHILD > {code} > That means this actually returns true: > {code} > isChildOf("src/main/java", "src/main/java-NOT-A-CHILD") > {code} > {code} > protected static boolean isChildOf(String parent, String child) { > if (parent == null || child == null) > return false; > if (!child.startsWith(parent)) > return false; > if (child.length() <= parent.length()) > return false; > int from = parent.equals(SEPARATOR) ? parent.length() : parent.length() + 1; > // if(from-1 > child.length()) > // return false; > String[] comps = Util.components(child.substring(from), SEPARATOR); > return comps != null && comps.length <= 1; > }{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3502) GridFile.isChildOf() incorrectly compares file paths.

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3502?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3502: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 6.0.0.Beta1 Resolution: Done > GridFile.isChildOf() incorrectly compares file paths. > ----------------------------------------------------- > > Key: ISPN-3502 > URL: https://issues.jboss.org/browse/ISPN-3502 > Project: Infinispan > Issue Type: Feature Request > Components: Core API > Affects Versions: 5.2.6.Final > Reporter: Lincoln Baxter III > Assignee: Lincoln Baxter III > Fix For: 6.0.0.Beta1 > > > This is the method in GridFile that is executed to compare paths. However, it doesn't compare the parent with a trailing `File.separator`, so all children with a path that starts with the parent path (even without a File.separator) are considered children. > E.g: > {code} > src/main/java > src/main/java-NOT-A-CHILD > {code} > That means this actually returns true: > {code} > isChildOf("src/main/java", "src/main/java-NOT-A-CHILD") > {code} > {code} > protected static boolean isChildOf(String parent, String child) { > if (parent == null || child == null) > return false; > if (!child.startsWith(parent)) > return false; > if (child.length() <= parent.length()) > return false; > int from = parent.equals(SEPARATOR) ? parent.length() : parent.length() + 1; > // if(from-1 > child.length()) > // return false; > String[] comps = Util.components(child.substring(from), SEPARATOR); > return comps != null && comps.length <= 1; > }{code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3489) REST cache store should use httpcomponents instead of httpclient

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3489?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-3489: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > REST cache store should use httpcomponents instead of httpclient > ---------------------------------------------------------------- > > Key: ISPN-3489 > URL: https://issues.jboss.org/browse/ISPN-3489 > Project: Infinispan > Issue Type: Component Upgrade > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha4 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 6.0.0.Beta1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3517) Infinispan server ignores persistence configuration

by Mircea Markus (JIRA)

Mircea Markus created ISPN-3517: ----------------------------------- Summary: Infinispan server ignores persistence configuration Key: ISPN-3517 URL: https://issues.jboss.org/browse/ISPN-3517 Project: Infinispan Issue Type: Feature Request Components: Server Affects Versions: 6.0.0.Alpha4 Reporter: Mircea Markus Assignee: Tristan Tarrant Fix For: 6.0.0.Beta1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2177) Refactor AbstractCacheTransaction

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2177?page=com.atlassian.jira.plugin.... ] Work on ISPN-2177 started by William Burns. > Refactor AbstractCacheTransaction > ----------------------------------- > > Key: ISPN-2177 > URL: https://issues.jboss.org/browse/ISPN-2177 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Affects Versions: 5.1.2.FINAL > Reporter: Mircea Markus > Assignee: William Burns > Labels: refactoring, transaction > Fix For: 6.0.0.CR1 > > > There are several collections holding transaction related information in the AbstractCacheTransaction: > - lockedKeys: this holds all the keys that were actually locked on the local node > - affectedKeys: this holds all the keys that were acquired by the transaction allover the cluster > - backupKeyLocks: this holds all the locks for which the local node is a secondary data owner. > To do: > - affectedKeys belongs to LocalCacheTransaction(subclass) and no point in having it in the AbstractCacheTransaction > - a better name for affectedKeys might be "clusterLockedKey" and for lockedKeys --> localLokedKeys > - also add a Javadoc explaining the correlation between these key groups -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 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 September 2013