September 2013 - infinispan-issues

[JBoss JIRA] (ISPN-3298) Can't retrieve evicted entries from FileCacheStore

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-3298?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-3298: ---------------------------------------- Even though it will be deprecated, existing EAP/JDG users could be suffering from this, assuming it's a bug, so definitely worth investigating it. It's odd though that this is not working. It's almost as if the cache store was not plugged to the Cache and instead you have a cache that evicts but data does not go to cache store. > Can't retrieve evicted entries from FileCacheStore > -------------------------------------------------- > > Key: ISPN-3298 > URL: https://issues.jboss.org/browse/ISPN-3298 > Project: Infinispan > Issue Type: Bug > Reporter: Jakub Markos > Assignee: Mircea Markus > Attachments: server.log > > > When using this configuration for the latest (6.0.0-SNAPSHOT) infinispan-server: > {code:xml} > <subsystem xmlns="urn:infinispan:server:core:5.3" default-cache-container="local"> > <cache-container name="local" default-cache="default"> > <local-cache name="default" start="EAGER"> > <locking isolation="NONE" acquire-timeout="30000" concurrency-level="1000" striping="false"/> > <transaction mode="NONE"/> > <eviction strategy="LRU" max-entries="5"/> > <file-store passivation="true" path="dc" purge="true" shared="false"/> > </local-cache> > </cache-container> > </subsystem> > {code} > and running this code: > {code} > for (int i = 0; i < 6; i++) { > cache.put("k" + i, "v" + i); > } > for (int i = 0; i < 6; i++) { > System.out.println("k" + i + ": " + cache.get("k" + i)); > } > {code} > I'm getting (reproducibly): > {quote} > k0: null > k1: v1 > k2: v2 > k3: null > k4: v4 > k5: v5 > {quote} > The directory $\{server\}/standalone/data/dc/default/ contains 2 files (with v0 and v3). > Server trace log attached. -- 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 Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/ISPN-3502?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III reassigned ISPN-3502: ---------------------------------------- Assignee: Lincoln Baxter III (was: Mircea Markus) > 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 > > 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 Lincoln Baxter III (JIRA)

[ https://issues.jboss.org/browse/ISPN-3502?page=com.atlassian.jira.plugin.... ] Lincoln Baxter III updated ISPN-3502: ------------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2065 > 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 > > 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 Lincoln Baxter III (JIRA)

Lincoln Baxter III created ISPN-3502: ---------------------------------------- Summary: 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: Mircea Markus 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-3501) Upgrade JGroups to 3.4.0.Alpha3

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3501?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3501: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2064 > 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-3501) Upgrade JGroups to 3.4.0.Alpha3

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3501: --------------------------------- Summary: 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-3500) Conditional operation can generate inconsistencies in transactional mode

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3500?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3500: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2063 > Conditional operation can generate inconsistencies in transactional mode > ------------------------------------------------------------------------ > > Key: ISPN-3500 > URL: https://issues.jboss.org/browse/ISPN-3500 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > conditional operation can be applied in the backup nodes. consider the following scenario: > {code} > k=v1 > tx1: write on key k value v2 > tx1: prepare and sends the commit... primary owner already applied v2 > tx2: [replace(k, v1, v3)] starts and reads from primary owner v2. ignoreReturnValue is false because the operation has failed to change k. > tx2: sends the prepare. in the backup owner, if perform oldValue.equals(value). however, the oldValue == v1 and value == v1. > {code} > the operation changed the key in the backup owner creating inconsistency. -- 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-3500) Conditional operation can generate inconsistencies in transactional mode

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3500?page=com.atlassian.jira.plugin.... ] Work on ISPN-3500 started by Pedro Ruivo. > Conditional operation can generate inconsistencies in transactional mode > ------------------------------------------------------------------------ > > Key: ISPN-3500 > URL: https://issues.jboss.org/browse/ISPN-3500 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.Alpha4 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Beta1 > > > conditional operation can be applied in the backup nodes. consider the following scenario: > {code} > k=v1 > tx1: write on key k value v2 > tx1: prepare and sends the commit... primary owner already applied v2 > tx2: [replace(k, v1, v3)] starts and reads from primary owner v2. ignoreReturnValue is false because the operation has failed to change k. > tx2: sends the prepare. in the backup owner, if perform oldValue.equals(value). however, the oldValue == v1 and value == v1. > {code} > the operation changed the key in the backup owner creating inconsistency. -- 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-3500) Conditional operation can generate inconsistencies in transactional mode

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-3500: --------------------------------- Summary: Conditional operation can generate inconsistencies in transactional mode Key: ISPN-3500 URL: https://issues.jboss.org/browse/ISPN-3500 Project: Infinispan Issue Type: Bug Affects Versions: 6.0.0.Alpha4 Reporter: Pedro Ruivo Assignee: Pedro Ruivo Fix For: 6.0.0.Beta1 conditional operation can be applied in the backup nodes. consider the following scenario: {code} k=v1 tx1: write on key k value v2 tx1: prepare and sends the commit... primary owner already applied v2 tx2: [replace(k, v1, v3)] starts and reads from primary owner v2. ignoreReturnValue is false because the operation has failed to change k. tx2: sends the prepare. in the backup owner, if perform oldValue.equals(value). however, the oldValue == v1 and value == v1. {code} the operation changed the key in the backup owner creating inconsistency. -- 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-3376) CLI upgrade command does not work

by Vitalii Chepeliuk (JIRA)

[ https://issues.jboss.org/browse/ISPN-3376?page=com.atlassian.jira.plugin.... ] Vitalii Chepeliuk updated ISPN-3376: ------------------------------------ Attachment: logs.zip Added server logs > CLI upgrade command does not work > --------------------------------- > > Key: ISPN-3376 > URL: https://issues.jboss.org/browse/ISPN-3376 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 6.0.0.Alpha1 > Reporter: Vitalii Chepeliuk > Assignee: Tristan Tarrant > Attachments: logs.zip, standalone-hotrod-rolling-upgrade.xml > > > Run my backup server with default standalone.xml configuration > ./standalone.sh -c standalone.xml -Djboss.socket.binding.port-offset=111 -Djboss.node.name=BACKUPER > Run my new server with > ./standalone.sh -c standalone-hotrod-rolling-upgrade.xml -Djboss.node.name=UPGRADER > 1) run command on BACKUPER > [remoting://localhost:10110/local/default]> upgrade --dumpkeys default > ISPN019502: Dumped keys for cache default > 2) run command on UPGRADER > [remoting://localhost:9999/local/default]> upgrade --synchronize=hotrod default > ISPN019026: An error occurred while synchronizing data for cache 'hotrod' using migrator 'default' from the source 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2013