[JBoss JIRA] (ISPN-3448) Tests from org.infinispan.distribution.rehash package fail randomly
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3448?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3448:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.1.0.Final
Resolution: Done
> Tests from org.infinispan.distribution.rehash package fail randomly
> -------------------------------------------------------------------
>
> Key: ISPN-3448
> URL: https://issues.jboss.org/browse/ISPN-3448
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.Alpha3, 6.0.0.CR1, 6.0.0.Final
> Reporter: Jiří Holuša
> Assignee: Mircea Markus
> Labels: testsuite_stability
> Fix For: 6.1.0.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent.log.zip, NonTxStateTransferOverwritingValue2Test.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove.log.zip, NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuring{Remove, Replace}WithPreviousValue.log.zip
>
>
> These tests are randomly failing on various platforms (RHEL, Solaris) with various JDKs.
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringJoinStressTest.testNodeJoiningDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxJoinerBecomingBackupOwnerTest.testBackupOwnerJoiningDuringPut
> org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemove
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringPutOverwrite
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringRemoveWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplaceWithPreviousValue
> org.infinispan.distribution.rehash.NonTxStateTransferOverwritingValue2Test.testBackupOwnerJoiningDuringReplace
--
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, 5 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by V L (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
V L commented on ISPN-3766:
---------------------------
Hi William. Thanks for your response.
{quote}That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value, which is a write skew (PFER has it's own transaction).{quote}
I think I got your logic on write skews, but now I'm fully understand the logic of PFER that described here http://infinispan.org/docs/6.0.x/user_guide/user_guide.html#_putforextern...
PFER purpose is to store values from data source for other readers, to improve performance. My sample shows that I can use it only for store data that can't be changed during current transaction ?
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> 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, 5 months
[JBoss JIRA] (ISPN-3742) StateTransferReplicationQueueTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3742?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3742:
------------------------------------
Looks like the test was *not* using initially async marshalling initially, this only got changed during the switch to the new programmatic configuration.
> StateTransferReplicationQueueTest random failures
> -------------------------------------------------
>
> Key: ISPN-3742
> URL: https://issues.jboss.org/browse/ISPN-3742
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> The writer thread in StateTransferReplicationQueueTest is too fast, and sometimes it generates so many writes that it takes more than 5 seconds for the second node to apply all of them.
> We should use a much smaller limit for the replication queue, and the test should wait until all the commands have been replicated instead of using an arbitrary timeout.
--
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, 5 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by V L (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
V L updated ISPN-3766:
----------------------
Description:
I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
1) begin tx -> create an new element -> commit tx.
2) wait until cache expires. cache is empty now
3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
here is my log:
TX BEGIN tx_status=6 thread=1
PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
TX COMMIT tx_status=0 thread=1
TX BEGIN. tx_status=6, thread=1
SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
TX COMMIT status=0 thread=1
ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
This works ok
I'm looking forward for you comments, maybe I'm doing something wrong.
Thanks
was:
I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
1) begin tx -> create an new element -> commit tx.
2) wait until cache expires. cache is empty now
3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
here is my log:
TX BEGIN tx_status=6 thread=1
PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
TX COMMIT tx_status=0 thread=1
TX BEGIN. tx_status=6, thread=1
SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
TX COMMIT status=0 thread=1
ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
I think I found the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
This works ok
I'm looking forward for you comments, maybe I'm doing something wrong.
Thanks
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> 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, 5 months
[JBoss JIRA] (ISPN-3742) StateTransferReplicationQueueTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3742?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3742:
------------------------------------
Ok, there seem to be 2 different ways in which the test can fail, because the test uses implicit transactions and every put() and remove() is in a separate transaction.
1. Because the test thread starts checking the values before the background thread finished replicating the commands, it's possible that the main thread will check a value right after the put transaction was executed on the 2nd node but before the remove.
2. Because the test uses async marshalling, it's actually possible for the put and the remove to be executed on the 2nd node in the wrong order (ISPN-2939). That will cause an inconsistency and cause the test to fail.
{noformat}
23:58:10,237 TRACE (WriterThread:nbst-replqueue) [RpcManagerImpl] NodeA-20050 invoking PrepareCommand {modifications=[PutKeyValueCommand{key=test7076, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66103:local, cacheName='nbst-replqueue', topologyId=4} to recipient list [NodeA-20050, NodeC-33979] with options RpcOptions{timeout=15000, unit=MILLISECONDS, fifoOrder=true, totalOrder=false, responseFilter=null, responseMode=ASYNCHRONOUS, skipReplicationQueue=false}
23:58:10,237 TRACE (WriterThread:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test7076 removed=false valid=true changed=true created=true loaded=false value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3 metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
23:58:10,257 TRACE (Scheduled-replicationQueue-thread-2759:nbst-replqueue) [RpcManagerImpl] NodeA-20050 invoking MultipleRpcCommand{commands=[32 x PrepareCommand, PrepareCommand {modifications=[PutKeyValueCommand{key=test7076, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66103:local, cacheName='nbst-replqueue', topologyId=4}], cacheName='nbst-replqueue'} to single recipient NodeC-33979 with response mode GET_NONE
23:58:10,259 TRACE (asyncTransportThread-5,NodeA:) [CommandAwareRpcDispatcher] Replication task sending MultipleRpcCommand{commands=[PrepareCommand {modifications=[32 x PrepareCommand, PrepareCommand {modifications=[PutKeyValueCommand{key=test7076, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66103:local, cacheName='nbst-replqueue', topologyId=4}], cacheName='nbst-replqueue'} to single recipient NodeC-33979 with response mode GET_NONE
23:58:10,263 TRACE (WriterThread:nbst-replqueue) [RpcManagerImpl] NodeA-20050 invoking PrepareCommand {modifications=[RemoveCommand{key=test7076, value=null, flags=null, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66104:local, cacheName='nbst-replqueue', topologyId=4} to recipient list [NodeA-20050, NodeC-33979] with options RpcOptions{timeout=15000, unit=MILLISECONDS, fifoOrder=true, totalOrder=false, responseFilter=null, responseMode=ASYNCHRONOUS, skipReplicationQueue=false}
23:58:10,263 TRACE (WriterThread:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test7076 removed=true valid=false changed=true created=false loaded=false value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3 metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
23:58:10,359 TRACE (Scheduled-replicationQueue-thread-2759:nbst-replqueue) [RpcManagerImpl] NodeA-20050 invoking MultipleRpcCommand{commands=[PrepareCommand {modifications=[RemoveCommand{key=test7076, value=null, flags=null, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66104:local, cacheName='nbst-replqueue', topologyId=4}, 27 x PrepareCommand], cacheName='nbst-replqueue'} to recipient list null with options RpcOptions{timeout=15000, unit=MILLISECONDS, fifoOrder=true, totalOrder=false, responseFilter=null, responseMode=ASYNCHRONOUS, skipReplicationQueue=true}
23:58:10,360 TRACE (asyncTransportThread-1,NodeA:) [CommandAwareRpcDispatcher] Replication task sending MultipleRpcCommand{commands=[PrepareCommand {modifications=[RemoveCommand{key=test7076, value=null, flags=null, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66104:local, cacheName='nbst-replqueue', topologyId=4}, 27 x PrepareCommand], cacheName='nbst-replqueue'} to single recipient NodeC-33979 with response mode GET_NONE
23:58:10,361 TRACE (asyncTransportThread-1,NodeA:) [CommandAwareRpcDispatcher] Response: null
23:58:15,261 TRACE (asyncTransportThread-5,NodeA:) [CommandAwareRpcDispatcher] Response: null
23:59:17,428 TRACE (Incoming-1,NodeC-33979:) [PrepareCommand] Invoking remotely originated prepare: PrepareCommand {modifications=[RemoveCommand{key=test7076, value=null, flags=null, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66104:local, cacheName='nbst-replqueue', topologyId=4} with invocation context: org.infinispan.context.impl.RemoteTxInvocationContext@3a27fd82
23:59:17,428 TRACE (Incoming-1,NodeC-33979:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test7076 removed=true valid=false changed=true created=true loaded=false value=null metadata=null, providedMetadata=null)
23:59:17,715 TRACE (Incoming-1,NodeC-33979:) [PrepareCommand] Invoking remotely originated prepare: PrepareCommand {modifications=[PutKeyValueCommand{key=test7076, value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=true}], onePhaseCommit=true, gtx=GlobalTransaction:<NodeA-20050>:66103:local, cacheName='nbst-replqueue', topologyId=4} with invocation context: org.infinispan.context.impl.RemoteTxInvocationContext@3a27fd81
23:59:17,716 TRACE (Incoming-1,NodeC-33979:nbst-replqueue) [ReadCommittedEntry] Updating entry (key=test7076 removed=false valid=true changed=true created=true loaded=false value=org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3 metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
00:00:00,914 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [CallInterceptor] Executing command: GetKeyValueCommand {key=test7076, flags=null}.
00:00:00,914 TRACE (testng-StateTransferReplicationQueueTest:nbst-replqueue) [GetKeyValueCommand] Found value org.infinispan.statetransfer.StateTransferReplicationQueueTest$PojoValue@1bc3
{noformat}
> StateTransferReplicationQueueTest random failures
> -------------------------------------------------
>
> Key: ISPN-3742
> URL: https://issues.jboss.org/browse/ISPN-3742
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Mircea Markus
> Labels: testsuite_stability
>
> The writer thread in StateTransferReplicationQueueTest is too fast, and sometimes it generates so many writes that it takes more than 5 seconds for the second node to apply all of them.
> We should use a much smaller limit for the replication queue, and the test should wait until all the commands have been replicated instead of using an arbitrary timeout.
--
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, 5 months
[JBoss JIRA] (ISPN-3769) Disallow async marshalling when the replication queue is enabled
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3769:
----------------------------------
Summary: Disallow async marshalling when the replication queue is enabled
Key: ISPN-3769
URL: https://issues.jboss.org/browse/ISPN-3769
Project: Infinispan
Issue Type: Task
Components: RPC
Affects Versions: 6.0.0.Final
Reporter: Dan Berindei
Assignee: Mircea Markus
Fix For: 7.0.0.Final
The rationale is similar to ISPN-2939, the async marshalling option can cause inconsistencies because it can reorder commands.
But the case is stronger when the replication queue is in use, because the {{RpcManager.invokeRemotely()}} call already happens on a the replication queue's background thread. The user thread is already free to do its thing, so there isn't any reason to do the RPC on yet another background thread.
--
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, 5 months
[JBoss JIRA] (ISPN-3766) "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3766?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3766:
-------------------------------------
It is still the expected behavior
* If I don't use "get" method everything is working ok.
It sounds like whatever method you are using doesn't detect write skews then (like #3 below)
* If cache already contains element before "get" invocation - everything is working ok
That is because the PFER doesn't actually modify the value since it is a putIfAbsent call (thus no write skew occurred)
* when I use my workaround for "containsKey" functional - everything is working ok (e.g cache.keySet().contains(key))
That is because you are bypassing all write skew checks and checking the data container directly. Which lets you do this write skew
{quote}
The problem is that I don't need to do read operation at 3, I need to check if element exists in the cache. I need a "containsKey" method, but this method has the same implementation as "get".
{quote}
That is because it also pays attention to write skews. In your case you are trying to later modify your value in the same transaction, but another transaction has changed the value (write skew) in another transaction (PFER has it's own transaction).
> "containsKey" and "get" methods are not working properly with "putForExternalRead" during active transaction. WriteSkewException appears.
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3766
> URL: https://issues.jboss.org/browse/ISPN-3766
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1, 6.0.0.Final
> Reporter: V L
> Assignee: Mircea Markus
> Attachments: InfinispanTest.java
>
>
> I'm not new with Infinispan, we use it from 5.3 version. Now I'm working on adding WriteSkew functional to our project, but unfortunately it's not working as we expected.
> We use infinispan like a cache for mongoDb data source, but this situation doesn't depends on data source vendor.
> The problem is that WriteSkewException is available in specific situation, here are steps for reproducing:
> 1) begin tx -> create an new element -> commit tx.
> 2) wait until cache expires. cache is empty now
> 3) being tx -> try to get element from cache, but it's not found -> load element from data source -> put it to the cache via putForExternalRead for read access outside of current transaction.
> 4) make some modification with element -> put element to cache -> commit tx -> WriteSkewException
> here is my log:
> TX BEGIN tx_status=6 thread=1
> PUT id=key1, tx_status=0, thread=1 cache_size=1, cache_ contains=key:key1, value:value
> TX COMMIT tx_status=0 thread=1
> TX BEGIN. tx_status=6, thread=1
> SIZE id=key1 tx_status=0, thread=1 cache_size=1 contains=key:key1, value:null
> PUT_FOR_EXTERNAL_READ id=key1, tx_status=0 thread=1 cache_size=1 cache_contains=key:key1, value:null
> PUT id=key1 tx_status=0 thread=1 cache_size=1 contains=key:key1, value:value
> TX COMMIT status=0 thread=1
> ISPN000005: Detected write skew on key [1]. Another process has changed the entry since we last read it! Unable to copy entry for update.
> Exception executing call org.infinispan.transaction.WriteSkewException: Detected write skew.
> I think I found the problem is in "get" method. When you invoke "get" method with key that not available in cache, infinispan create an "null" element in cache. This element won't be updated by putForExternalRead method (look at log above). If you skip "get" method invocation everithing will work fine. By the way, everithing is working fine if you skip "step 2" of the scenario.
> I use workaround for this situation. I check if element exist in the cache not by "containsKey" or "get" method but via cache.keySet().contains(key)
> This works ok
> I'm looking forward for you comments, maybe I'm doing something wrong.
> 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, 5 months