[JBoss JIRA] (ISPN-3677) With optimistic TX, conditional commands may wrongly succeed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3677?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-3677:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1026221
> With optimistic TX, conditional commands may wrongly succeed
> ------------------------------------------------------------
>
> Key: ISPN-3677
> URL: https://issues.jboss.org/browse/ISPN-3677
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Situation with optimistic TX, originator = entry's primary owner:
> 1. The conditional check suceeds when the command is executed
> 2. In TxDistributionInterceptor, ignorePreviousValue is set to true
> 3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
> 4. During the prepare/commit phase the command ignores the condition
> Result:
> Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3677) With optimistic TX, conditional commands may wrongly succeed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3677?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3677:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1026221|https://bugzilla.redhat.com/show_bug.cgi?id=1026221]
Situation with optimistic TX, originator = entry's primary owner:
1. The conditional check suceeds when the command is executed
2. In TxDistributionInterceptor, ignorePreviousValue is set to true
3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
4. During the prepare/commit phase the command ignores the condition
Result:
Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
> With optimistic TX, conditional commands may wrongly succeed
> ------------------------------------------------------------
>
> Key: ISPN-3677
> URL: https://issues.jboss.org/browse/ISPN-3677
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Situation with optimistic TX, originator = entry's primary owner:
> 1. The conditional check suceeds when the command is executed
> 2. In TxDistributionInterceptor, ignorePreviousValue is set to true
> 3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
> 4. During the prepare/commit phase the command ignores the condition
> Result:
> Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3677) With optimistic TX, conditional commands may wrongly succeed
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3677:
---------------------------------
Summary: With optimistic TX, conditional commands may wrongly succeed
Key: ISPN-3677
URL: https://issues.jboss.org/browse/ISPN-3677
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 6.0.0.CR1
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
Situation with optimistic TX, originator = entry's primary owner:
1. The conditional check suceeds when the command is executed
2. In TxDistributionInterceptor, ignorePreviousValue is set to true
3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
4. During the prepare/commit phase the command ignores the condition
Result:
Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-3665:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2180
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: 620
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro reassigned ISPN-3665:
----------------------------------
Assignee: Paul Ferraro (was: Mircea Markus)
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: 620
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3676) review jgroups-tcp.xml comment about ergonomics
by Mathieu Lachance (JIRA)
Mathieu Lachance created ISPN-3676:
--------------------------------------
Summary: review jgroups-tcp.xml comment about ergonomics
Key: ISPN-3676
URL: https://issues.jboss.org/browse/ISPN-3676
Project: Infinispan
Issue Type: Task
Components: Configuration
Affects Versions: 6.0.0.CR1
Reporter: Mathieu Lachance
Assignee: Mircea Markus
jgroups-tcp.xml:
<!-- Ergonomics, new in JGroups 2.11, are disabled by default in TCPPING until JGRP-1253 is resolved -->
<!--
<TCPPING timeout="3000"
initial_hosts="localhost[7800],localhost[7801]"
port_range="5"
num_initial_members="3"
ergonomics="false"
/>
-->
JGRP-1253
TCPPING: ergononics sets return_entire_cache to false, needs to be overridden
has been resolved.
jgroups-tcp.xml should be adapted and updated.
Thanks.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-3665 at 11/1/13 5:00 PM:
-------------------------------------------------------------
So, here are the issues I see with SingleFileStore:
* Both start() and stop() set the values of a number of non-volatile fields. These changes are not guaranteed to be visible to threads calling operations such as write(...), delete(...), etc. Making these methods synchronized would fix this problem.
* -write(MarshalledEntry) sets the values of a number of non-volatile fields of the FileEntry object. These changes are not guaranteed to be visible to other threads. Making these fields volatile would fix this problem.- Actually, this looks OK. Visibility to these fields is ensured by the entries monitor.
* delete(...) calls free(FileEntry), which zeros out the portion of the file even though other threads might be reading the value. Dan alluded to this issue above.
* load(...) also calls free(FileEntry) if the entry is expired even though other threads might be reading the value.
was (Author: pferraro):
So, here are the issues I see with SingleFileStore:
* Both start() and stop() set the values of a number of non-volatile fields. These changes are not guaranteed to be visible to threads calling operations such as write(...), delete(...), etc. Making these methods synchronized would fix this problem.
* -write(MarshalledEntry) sets the values of a number of non-volatile fields of the FileEntry object. These changes are not guaranteed to be visible to other threads. Making these fields volatile would fix this problem.- Actually, this looks OK. Visibility to these fields is ensured by the entries monitor.
* delete(...) calls free(FileEntry), which zeros out the portion of the file even though other threads might be reading the value. Dan alluded to this issue above.
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: 620
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-3665 at 11/1/13 4:53 PM:
-------------------------------------------------------------
So, here are the issues I see with SingleFileStore:
* Both start() and stop() set the values of a number of non-volatile fields. These changes are not guaranteed to be visible to threads calling operations such as write(...), delete(...), etc. Making these methods synchronized would fix this problem.
* -write(MarshalledEntry) sets the values of a number of non-volatile fields of the FileEntry object. These changes are not guaranteed to be visible to other threads. Making these fields volatile would fix this problem.- Actually, this looks OK. Visibility to these fields is ensured by the entries monitor.
* delete(...) calls free(FileEntry), which zeros out the portion of the file even though other threads might be reading the value. Dan alluded to this issue above.
was (Author: pferraro):
So, here are the issues I see with SingleFileStore:
* Both start() and stop() set the values of a number of non-volatile fields. These changes are not guaranteed to be visible to threads calling operations such as write(...), delete(...), etc. Making these methods synchronized would fix this problem.
* write(MarshalledEntry) sets the values of a number of non-volatile fields of the FileEntry object. These changes are not guaranteed to be visible to other threads. Making these fields volatile would fix this problem.
* delete(...) calls free(FileEntry), which zeros out the portion of the file even though other threads might be reading the value. Dan alluded to this issue above.
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: 620
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-3665:
------------------------------------
So, here are the issues I see with SingleFileStore:
* Both start() and stop() set the values of a number of non-volatile fields. These changes are not guaranteed to be visible to threads calling operations such as write(...), delete(...), etc. Making these methods synchronized would fix this problem.
* write(MarshalledEntry) sets the values of a number of non-volatile fields of the FileEntry object. These changes are not guaranteed to be visible to other threads. Making these fields volatile would fix this problem.
* delete(...) calls free(FileEntry), which zeros out the portion of the file even though other threads might be reading the value. Dan alluded to this issue above.
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
> Priority: Blocker
> Labels: 620
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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
10 years, 6 months