[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
[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
[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
[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
[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
[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
[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
[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