[JBoss JIRA] (ISPN-5042) Remote gets caused by writes could be replicated only to the primary owner
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5042?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5042:
----------------------------------
Labels: 7.0 (was: )
> Remote gets caused by writes could be replicated only to the primary owner
> --------------------------------------------------------------------------
>
> Key: ISPN-5042
> URL: https://issues.jboss.org/browse/ISPN-5042
> Project: Infinispan
> …
[View More]Issue Type: Enhancement
> Components: Core, State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Labels: 7.0
> Fix For: 7.1.0.Final
>
>
> For write operations that need the previous value, a write CH-only owner that doesn't have a key locally will attempt to retrieve the key from the read CH-owners.
> Sending the remote get command to all the previous owners will create extra load on the cluster during state transfer, so it should be more efficient to send the remote get only to the primary owner. Even though the latency of some write operations will be higher, the average latency should be better.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5076) Pessimistic transactions can lose their locks when the primary owner changes
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5076?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5076:
----------------------------------
Labels: 7.0 (was: )
> Pessimistic transactions can lose their locks when the primary owner changes
> ----------------------------------------------------------------------------
>
> Key: ISPN-5076
> URL: https://issues.jboss.org/browse/ISPN-5076
> Project: Infinispan
> …
[View More] Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 7.0
> Fix For: 7.1.0.Final
>
>
> In a pessimistic cache, if a transaction {{T1}} has a {{put(k, v})}} operation and the primary owner of the key is the originator, the lock is acquired on the originator but it is not replicated to on the backup(s).
> If one of the backup owners becomes the primary owner, it will allow another transaction {{T2}} to lock (and update) key {{k}} before it receives the one-phase prepare command from the originator of {{T1}}.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5088) Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5088?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5088:
----------------------------------
Labels: 7.0 for_OGM (was: for_OGM)
> Deleted entries from (FineGrained)AtomicMap reappear in subsequent transaction
> ------------------------------------------------------------------------------
>
> Key: ISPN-5088
> URL: https://issues.jboss.org/browse/ISPN-5088
> Project: …
[View More]Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Sanne Grinovero
> Assignee: William Burns
> Priority: Critical
> Labels: 7.0, for_OGM
> Attachments: Testcase-ISPN-5088.patch
>
>
> After a {{FineGrainedAtomicMap}} containing some data is deleted in a transaction, but then in the same transaction it's re-created, the next transaction will be able to read the original data which it contained.
> Some pseudocode:
> {code}tx1.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k1, v1);
> tx1.commit()
> tx2.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k3, v3);
> AtomicMapLookup.removeAtomicMap( cache, cacheKey );
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.put(k2,v2);
> tx2.commit()
> tx3.start();
> am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true );
> am.contains(k1) == false; // FAILS!
> tx3.commit();{code}
> Also applies apparently to a normal AtomicMap if using DIST_SYNC.
> I'm attaching a full test, which results in:
> {noformat}
> Failed tests:
> RepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> FineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistRepeatableReadAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> DistAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null
> Tests run: 5636, Failures: 6, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-4586) Too many OutdatedTopologyExceptions in non-transactional caches
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4586?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4586:
----------------------------------
Labels: 7.0 performance (was: performance)
> Too many OutdatedTopologyExceptions in non-transactional caches
> ---------------------------------------------------------------
>
> Key: ISPN-4586
> URL: https://issues.jboss.org/browse/ISPN-4586
> Project: Infinispan
> …
[View More] Issue Type: Enhancement
> Components: Core
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Labels: 7.0, performance
> Fix For: 7.1.0.Beta1
>
>
> In a non-tx cache, when the topology id is incremented, owners (both primary and backup) receiving a write command with a lower topology id throw an OutdatedTopologyException so that the originator retries the command on the new owners.
> But the originator needs to retry the command only if the owners of the key changed in any way. During a join or a leave, most of the keys should not change owners, so throwing an OutdatedTopologyException is not necessary most of the time.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5027) OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5027?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant reassigned ISPN-5027:
-------------------------------------
Assignee: Dan Berindei
> OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-5027
> URL: https://issues.jboss.org/browse/ISPN-5027
> …
[View More] Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Optional
> Fix For: 7.1.0.Beta1, 7.0.3.Final
>
>
> {{DistributedEntryRetriever}} pre-allocates an {{ArrayDeque}} and and {{ArrayBlockingQueue}} of the same size as the state transfer chunk size.
> {{ReplStateTransferCacheLoaderTest}} sets the state transfer chunk size to {{Integer.MAX_VALUE}}, so it will trigger an {{OutOfMemoryError}} at the end of the test, when {{TestingUtil.killCaches()}} tries to log the contents of the cache (if TRACE logging is enabled).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months
[JBoss JIRA] (ISPN-5027) OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5027?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5027:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> OutOfMemoryError in entry retriever when state transfer chunk size is Integer.MAX_VALUE
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-5027
> URL: https://issues.jboss.…
[View More]org/browse/ISPN-5027
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 7.0.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Optional
> Fix For: 7.1.0.Beta1, 7.0.3.Final
>
>
> {{DistributedEntryRetriever}} pre-allocates an {{ArrayDeque}} and and {{ArrayBlockingQueue}} of the same size as the state transfer chunk size.
> {{ReplStateTransferCacheLoaderTest}} sets the state transfer chunk size to {{Integer.MAX_VALUE}}, so it will trigger an {{OutOfMemoryError}} at the end of the test, when {{TestingUtil.killCaches()}} tries to log the contents of the cache (if TRACE logging is enabled).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
[View Less]
10 years, 2 months