July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer

by Erik Salter (JIRA)

[ https://issues.jboss.org/browse/ISPN-3389?page=com.atlassian.jira.plugin.... ] Erik Salter commented on ISPN-3389: ----------------------------------- As an illustration, look for GlobalTransaction:<west-dht1-8815(CH2-Chicago-IL)>:58590:local Here is where the tx is created: https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/originating_node/s... Here is the end result after the tx is forwarded: https://dl.dropboxusercontent.com/u/50401510/ISPN-3389/forwarded_node/OOB... > Forwarded transactions can remain stale after state transfer > ------------------------------------------------------------ > > Key: ISPN-3389 > URL: https://issues.jboss.org/browse/ISPN-3389 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.7.Final > Reporter: Erik Salter > Assignee: Mircea Markus > > There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table. > The chain of events is as follows: > 1. New topology comes in as part of a view change. > 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks. > 3. Tx forwarded to new owner. > 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners. > This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3389) Forwarded transactions can remain stale after state transfer

by Erik Salter (JIRA)

Erik Salter created ISPN-3389: --------------------------------- Summary: Forwarded transactions can remain stale after state transfer Key: ISPN-3389 URL: https://issues.jboss.org/browse/ISPN-3389 Project: Infinispan Issue Type: Bug Components: State transfer Affects Versions: 5.2.7.Final Reporter: Erik Salter Assignee: Mircea Markus There is a scenario where a tx started on one node, moved during state transfer, and committed on the originating node won't be removed from the new owner's tx table. The chain of events is as follows: 1. New topology comes in as part of a view change. 2. Local transaction started with the new topology ID. This transaction was started due to a LockControlCommand and has no modifications. Also important, it only has local locks. 3. Tx forwarded to new owner. 4. Since the tx has only local locks and no modifications, it is only removed locally. No TxCompletion or Rollback are broadcast to the new owners. This key becomes unusable not due to stale locks, but because the waitForTransaction() code will see that the old tx can "potentially" lock the key. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3388) Make sure legacy stores + loaders still work after configuration overhaul

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-3388: ------------------------------------- Summary: Make sure legacy stores + loaders still work after configuration overhaul Key: ISPN-3388 URL: https://issues.jboss.org/browse/ISPN-3388 Project: Infinispan Issue Type: Feature Request Components: Configuration, Loaders and Stores Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Blocker Fix For: 6.0.0.Alpha3 -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3276) Remove usages of CacheLoaderConfig

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3276?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3276: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/1993 > Remove usages of CacheLoaderConfig > ---------------------------------- > > Key: ISPN-3276 > URL: https://issues.jboss.org/browse/ISPN-3276 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 6.0.0.Alpha1 > Reporter: Navin Surtani > Assignee: Navin Surtani > > As part of the Configuration migration, we need to remove all usages of CacheLoaderConfig and change them to CacheLoaderConfiguration usages. > This will involve making changes to how implementations of org.infinispan.loaders.CacheLoader work along with their respective constructors. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3157) Realign Infinispan subsystem to match AS7.2/EAP6.1

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3157?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3157: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] i have not been able to check-in my code, here is a source patch file > Realign Infinispan subsystem to match AS7.2/EAP6.1 > -------------------------------------------------- > > Key: ISPN-3157 > URL: https://issues.jboss.org/browse/ISPN-3157 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Fix For: 5.3.0.Final > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3227) Server loader configuration breaks when properties are specified

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3227?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3227: ----------------------------------------------- Shay Matasaro <smatasar(a)redhat.com> made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] i have not been able to check-in my code, here is a source patch file > Server loader configuration breaks when properties are specified > ---------------------------------------------------------------- > > Key: ISPN-3227 > URL: https://issues.jboss.org/browse/ISPN-3227 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Affects Versions: 5.2.6.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.2.7.Final > > -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3387) AsyncStore preload is slow, when given database datastore

by Laszlo Hadadi (JIRA)

Laszlo Hadadi created ISPN-3387: ----------------------------------- Summary: AsyncStore preload is slow, when given database datastore Key: ISPN-3387 URL: https://issues.jboss.org/browse/ISPN-3387 Project: Infinispan Issue Type: Task Components: Loaders and Stores Affects Versions: 5.3.0.Final Environment: database datastore, with AsyncStore Reporter: Laszlo Hadadi Assignee: Mircea Markus Priority: Minor Currently AsyncStore.loadAll() method strategy is suboptimal. actually loadAll do this: getAll keys from cache itarate on keys and load each value from store. This is can be really costly when we have db persistance behind async store. cost: 1 query for keys + number of keys query. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2903) Manual eviction should not delete entry from cache store

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-2903?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-2903: ----------------------------------------------- Radoslav Husar <rhusar(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] @Aleks, the fix have made it to 6.1.1.ER4, not earlier. > Manual eviction should not delete entry from cache store > -------------------------------------------------------- > > Key: ISPN-2903 > URL: https://issues.jboss.org/browse/ISPN-2903 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 5.2.3.Final > Reporter: Paul Ferraro > Assignee: Galder Zamarreño > Priority: Critical > Labels: 5.2.x, jdg6 > Fix For: 5.2.5.Final, 5.3.0.Alpha1, 5.3.0.Final > > Attachments: AtomicMapServlet.java, AtomicMapTestCase.java, server.log, server.log > > > Here's the scenario: > Given 2 nodes with REPL_SYNC cache with passivating cache store (e.g. default web cache in AS7). > 1. Create cache entry containing atomic map with 2 map entries on node1. > 2. Passivate that cache entry on node2 via manual evict. > 3. Modify 1 of the atomic map entries within the cache entry on node1. > 4. Lookup atomic map on node2. It only contains 1 map entry - the map entry modified in step 3. The other map entry is lost. > It's a side effect of ISPN-2384, where some changes were made to tighten the passivation/activation scenarios, but it did not cover manual eviction calls. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3366) Data loss when entry forwarding to primary owner and primary owner shutdown

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3366?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3366: ------------------------------------ Right, {{strictPeerToPeer}} is only available in the standalone Infinispan configuration, and not in the Infinispan Server configuration. > Data loss when entry forwarding to primary owner and primary owner shutdown > --------------------------------------------------------------------------- > > Key: ISPN-3366 > URL: https://issues.jboss.org/browse/ISPN-3366 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: ISPN-3366-logs.zip > > > Looks like a problem in entry forwarding. > Here is test scenario: > * DIST numOwners=2, start with 4 nodes cluster then normal shutdown 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 26608 > * node2: 26622 > * node3: 26746 > * node4: 0 > Total is 79976 and HotRod client received 11 errors, so 79976 + (11 * 2) = 79998. It means 1 entry is completely missing. > Let's take a look at the missing entry, hash(thread16key59) = 574ff563. > Current CH: owners(574ff563) are [node4, node1] > The events sequence is: > * hotrod -> node1 > * node1 forwarding it to primary owner node4 > * node4 doesn't process the forwarded entry, shutdown > Result owners(7c29bccb) is [] empty. This entry is completely lost without any errors. -- 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, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3366) Data loss when entry forwarding to primary owner and primary owner shutdown

by Takayoshi Kimura (JIRA)

[ https://issues.jboss.org/browse/ISPN-3366?page=com.atlassian.jira.plugin.... ] Takayoshi Kimura commented on ISPN-3366: ---------------------------------------- Looks like we don't have strictPeerToPeer configuration in Infinispan Server 5.2.x. > Data loss when entry forwarding to primary owner and primary owner shutdown > --------------------------------------------------------------------------- > > Key: ISPN-3366 > URL: https://issues.jboss.org/browse/ISPN-3366 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.2.4.Final, 6.0.0.Alpha1 > Reporter: Takayoshi Kimura > Assignee: Dan Berindei > Priority: Critical > Attachments: ISPN-3366-logs.zip > > > Looks like a problem in entry forwarding. > Here is test scenario: > * DIST numOwners=2, start with 4 nodes cluster then normal shutdown 1 node during load > * HotRod putIfAbsent accesses from 40 threads (1 process, 1 remote cache instance), 40000 entries total > After the test run, the numberOfEntries on each node are: > * node1: 26608 > * node2: 26622 > * node3: 26746 > * node4: 0 > Total is 79976 and HotRod client received 11 errors, so 79976 + (11 * 2) = 79998. It means 1 entry is completely missing. > Let's take a look at the missing entry, hash(thread16key59) = 574ff563. > Current CH: owners(574ff563) are [node4, node1] > The events sequence is: > * hotrod -> node1 > * node1 forwarding it to primary owner node4 > * node4 doesn't process the forwarded entry, shutdown > Result owners(7c29bccb) is [] empty. This entry is completely lost without any errors. -- 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, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013