July 2013 - infinispan-issues - Jboss List Archives

[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: ----------------------------------------------- dereed(a)redhat.com made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] Actually, looking at this again the schema is already correct, it's just the missing code that's the bug. So just backporting ISPN-3227 to add the code for reading/writing the XML should be sufficient. (It looks like the code to apply the properties is already there). > 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

12 years, 9 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: ----------------------------------------------- dereed(a)redhat.com made a comment on [bug 973763|https://bugzilla.redhat.com/show_bug.cgi?id=973763] Actually, looking at this again the schema is already correct, it's just the missing code that's the bug. So just backporting ISPN-3227 to add the code for reading/writing the XML should be sufficient. (It looks like the code to apply the properties is already there). > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-2950: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/1956 > In distributed mode cache store data should be read through the main data owner (vs directly from the store) > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2950 > URL: https://issues.jboss.org/browse/ISPN-2950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: William Burns > Priority: Blocker > Labels: onboard > Fix For: 6.0.0.Final > > > Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks: > - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this) > - if this is a local cache store, it might contain stale data which would be returned to the user > - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.) > This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-2950: ------------------------------------- Also I don't think it is feasible to limit this to only the primary data owner. By doing that we would also have to limit all gets when a cache loader is enabled to only ever hit the data owner which would cause a read scalability issue. Also owners that aren't primary don't ask the primary owner for data. A non shared cache store would persist to both locations as well. As long as the cluster doesn't go down then it should be consistent. Once the cluster goes down and if purgeOnStartup isn't enabled then there is no way to guarantee if data is stale or not in the cache store. > In distributed mode cache store data should be read through the main data owner (vs directly from the store) > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2950 > URL: https://issues.jboss.org/browse/ISPN-2950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: William Burns > Priority: Blocker > Labels: onboard > Fix For: 6.0.0.Final > > > Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks: > - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this) > - if this is a local cache store, it might contain stale data which would be returned to the user > - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.) > This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2950) In distributed mode cache store data should be read through the main data owner (vs directly from the store)

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-2950?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-2950: ------------------------------------- We can't remove the ClusterCacheLoader. It could be used in the context of a non dist cache as well. https://github.com/wburns/infinispan/blob/master/core/src/main/release/et... > In distributed mode cache store data should be read through the main data owner (vs directly from the store) > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-2950 > URL: https://issues.jboss.org/browse/ISPN-2950 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Sanne Grinovero > Assignee: William Burns > Priority: Blocker > Labels: onboard > Fix For: 6.0.0.Final > > > Dist cache with a cache store (shared or not), k owned by \{N1, N2\}. k is read on N3. What currently happens at this stage, if k is not present in N3's memory (likely unless L1 is configured), the N3's cache store is queried and data is loaded from there. This has several drawbacks: > - the data might already be in the memory of the owner node (N1,N2) so reading it from the disk is highly inefficient. Especially for hot data: data requested from various nodes at the same time (see also mailing list discussion around lucene query performance depending on this) > - if this is a local cache store, it might contain stale data which would be returned to the user > - for async configured cache store this would result in dirty reads, given that a change might be in the async store's memory but not in the store at the moment when it is in read by N3. (Note that using async stores still leaves place to inconsistencies when a node leaves, e.g. because of node crashing before managing to flush the async store.) > This JIRA is about changing the distribution mode: when asked for a specific key, a node would only touch a cache store if it is an owner of that key, otherwise would first go to the main owner of the key to read the value from there. The ClusterCacheLoader should be deprecated as well. -- 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, 9 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: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> made a comment on [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] https://github.com/jbossas/jboss-eap/pull/222 > 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

12 years, 9 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: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 900549|https://bugzilla.redhat.com/show_bug.cgi?id=900549] from ASSIGNED to POST > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3299) ReplTotalOrderStateTransferFunctional1PcTest.testSTWithThirdWritingTxCache random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3299?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3299: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ReplTotalOrderStateTransferFunctional1PcTest.testSTWithThirdWritingTxCache random failures > ------------------------------------------------------------------------------------------ > > Key: ISPN-3299 > URL: https://issues.jboss.org/browse/ISPN-3299 > Project: Infinispan > Issue Type: Bug > Components: RPC, State transfer > Affects Versions: 5.3.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final > > Attachments: rtostf1pt.log.gz > > > ReplTotalOrderStateTransferFunctional1PcTest.testSTWithThirdWritingTxCache sometimes times out. It seems to deadlock because a VersionedPrepareCommand and the REBALANCE_START command are delivered in different order on two different nodes: > {noformat} > 01:27:31,740 TRACE (Incoming-2,ISPN,NodeL-3115:) [CommandAwareRpcDispatcher] Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=repl-to-1pc-nbst, type=REBALANCE_START, sender=NodeK-31445, joinInfo=null, topologyId=3, currentCH=ReplicatedConsistentHash{members=[NodeK-31445, NodeL-3115], numSegments=1, primaryOwners=[0]}, pendingCH=ReplicatedConsistentHash{members=[NodeK-31445, NodeL-3115, NodeM-36388], numSegments=1, primaryOwners=[0]}, throwable=null, viewId=2} [sender=NodeK-31445] > 01:27:31,740 TRACE (Incoming-1,ISPN,NodeK-31445:) [CommandAwareRpcDispatcher] Attempting to execute command: VersionedPrepareCommand {modifications=[PutKeyValueCommand{key=test12, value=12, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, versionsSeen={test12=null}, gtx=GlobalTransaction:<NodeL-3115>:22544:local, cacheName='repl-to-1pc-nbst'} [sender=NodeL-3115] > 01:27:31,740 TRACE (Incoming-3,ISPN,NodeL-3115:) [CommandAwareRpcDispatcher] Attempting to execute command: VersionedPrepareCommand {modifications=[PutKeyValueCommand{key=test12, value=12, flags=null, putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true}], onePhaseCommit=false, versionsSeen={test12=null}, gtx=GlobalTransaction:<NodeL-3115>:22544:local, cacheName='repl-to-1pc-nbst'} [sender=NodeL-3115] > 01:27:31,741 TRACE (Incoming-3,ISPN,NodeL-3115:) [TotalOrderManager] Transaction [NodeL-3115:22544] will wait for [TotalOrderLatchImpl{latch=java.util.concurrent.CountDownLatch@5868f0ca[Count = 1], name='StateTransfer-3'}] and locked [test12] > 01:27:31,741 TRACE (Incoming-2,ISPN,NodeK-31445:) [CommandAwareRpcDispatcher] Attempting to execute non-CacheRpcCommand command: CacheTopologyControlCommand{cache=repl-to-1pc-nbst, type=REBALANCE_START, sender=NodeK-31445, joinInfo=null, topologyId=3, currentCH=ReplicatedConsistentHash{members=[NodeK-31445, NodeL-3115], numSegments=1, primaryOwners=[0]}, pendingCH=ReplicatedConsistentHash{members=[NodeK-31445, NodeL-3115, NodeM-36388], numSegments=1, primaryOwners=[0]}, throwable=null, viewId=2} [sender=NodeK-31445] > 01:27:31,741 TRACE (Incoming-2,ISPN,NodeK-31445:repl-to-1pc-nbst) [TotalOrderManager] State Transfer start. It will wait for [TotalOrderLatchImpl{latch=java.util.concurrent.CountDownLatch@51988b1e[Count = 1], name='NodeL-3115:22544'}] > {noformat} -- 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, 9 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] the complexity for this patch is really increased due to schema changes, i dont think its worth it how about using a store with pre-load configured but no persistence will that work as a workaround? > 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

12 years, 9 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] the complexity for this patch is really increased due to schema changes, i dont think its worth it how about using a store with pre-load configured but no persistence will that work as a workaround? > 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

12 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2013