May 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3106) Remove support for non-concurrent non-transactional distributed caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3106?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3106: -------------------------------- Fix Version/s: 5.3.0.Final > Remove support for non-concurrent non-transactional distributed caches > ---------------------------------------------------------------------- > > Key: ISPN-3106 > URL: https://issues.jboss.org/browse/ISPN-3106 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Distributed Cache, Locking and Concurrency > Affects Versions: 5.3.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > LockingConfigurationBuilder.supportsConcurrentUpdates() and LockingConfiguration.supportsConcurrentUpdates() should be deprecated. This config option should be assumed true and support for the non-concurrent case should be dropped to simplify distribution and locking interceptor hierarchy. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3106) Remove support for non-concurrent non-transactional distributed caches

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3106?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3106: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove support for non-concurrent non-transactional distributed caches > ---------------------------------------------------------------------- > > Key: ISPN-3106 > URL: https://issues.jboss.org/browse/ISPN-3106 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Distributed Cache, Locking and Concurrency > Affects Versions: 5.3.0.Beta1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 5.3.0.Beta2, 5.3.0.Final > > > LockingConfigurationBuilder.supportsConcurrentUpdates() and LockingConfiguration.supportsConcurrentUpdates() should be deprecated. This config option should be assumed true and support for the non-concurrent case should be dropped to simplify distribution and locking interceptor hierarchy. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2806) Add a more efficient FileCacheStore implementation

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2806?page=com.atlassian.jira.plugin.... ] Dan Berindei edited comment on ISPN-2806 at 5/16/13 9:16 AM: ------------------------------------------------------------- We already have two FileCacheStore redesign proposals, by Karsten Blees (https://github.com/infinispan/infinispan/issues/1282) and Patrick Azogni (https://github.com/infinispan/infinispan/pull/1644). was (Author: dan.berindei): We already have two FileCacheStore redesign proposals, by Karsten Blees and Patrick Azogni. > Add a more efficient FileCacheStore implementation > -------------------------------------------------- > > Key: ISPN-2806 > URL: https://issues.jboss.org/browse/ISPN-2806 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Based on the feedback we got from community/users Infinispan needs a more efficient FileCacheStore implementation. See the [design document|https://community.jboss.org/wiki/FileCacheStoreRedesign] that contains several suggestion of implementing it. It would be nice to also have a benchmark written in order to evaluate the performance between various implementation suggestion. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2806) Add a more efficient FileCacheStore implementation

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2806?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2806: ------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/issues/1282, https://github.com/infinispan/infinispan/pull/1644 We already have two FileCacheStore redesign proposals, by Karsten Blees and Patrick Azogni. > Add a more efficient FileCacheStore implementation > -------------------------------------------------- > > Key: ISPN-2806 > URL: https://issues.jboss.org/browse/ISPN-2806 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Mircea Markus > Assignee: Dan Berindei > Priority: Critical > Fix For: 6.0.0.Final > > > Based on the feedback we got from community/users Infinispan needs a more efficient FileCacheStore implementation. See the [design document|https://community.jboss.org/wiki/FileCacheStoreRedesign] that contains several suggestion of implementing it. It would be nice to also have a benchmark written in order to evaluate the performance between various implementation suggestion. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3008) HotRod Servers sharing a container should use separate topology caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant commented on ISPN-3008: --------------------------------------- [~NadirX] doesn't know what he's saying :) > HotRod Servers sharing a container should use separate topology caches > ----------------------------------------------------------------------- > > Key: ISPN-3008 > URL: https://issues.jboss.org/browse/ISPN-3008 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Beta2 > > > The HotRod Server always creates a topology cache using a fixed name. If the same cache container is shared by multiple endpoints this causes problems, since the HotRod server stores the externally facing address in the cache, and this will be different between endpoints. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3008) HotRod Servers sharing a container should use separate topology caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3008: ---------------------------------- Summary: HotRod Servers sharing a container should use separate topology caches (was: HotRod Servers sharing a container should check for a compatible topology cache) > HotRod Servers sharing a container should use separate topology caches > ----------------------------------------------------------------------- > > Key: ISPN-3008 > URL: https://issues.jboss.org/browse/ISPN-3008 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Beta2 > > > The HotRod Server always creates a topology cache. If the same cache container is shared by multiple endpoints this causes problems. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3008) HotRod Servers sharing a container should use separate topology caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3008: ---------------------------------- Description: The HotRod Server always creates a topology cache using a fixed name. If the same cache container is shared by multiple endpoints this causes problems, since the HotRod server stores the externally facing address in the cache, and this will be different between endpoints. (was: The HotRod Server always creates a topology cache. If the same cache container is shared by multiple endpoints this causes problems.) > HotRod Servers sharing a container should use separate topology caches > ----------------------------------------------------------------------- > > Key: ISPN-3008 > URL: https://issues.jboss.org/browse/ISPN-3008 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Beta2 > > > The HotRod Server always creates a topology cache using a fixed name. If the same cache container is shared by multiple endpoints this causes problems, since the HotRod server stores the externally facing address in the cache, and this will be different between endpoints. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3008) HotRod Servers sharing a container should use separate topology caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3008?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3008: ---------------------------------- Status: Open (was: Pull Request Sent) > HotRod Servers sharing a container should use separate topology caches > ----------------------------------------------------------------------- > > Key: ISPN-3008 > URL: https://issues.jboss.org/browse/ISPN-3008 > Project: Infinispan > Issue Type: Task > Components: Remote protocols > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 5.3.0.Beta2 > > > The HotRod Server always creates a topology cache using a fixed name. If the same cache container is shared by multiple endpoints this causes problems, since the HotRod server stores the externally facing address in the cache, and this will be different between endpoints. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3055) Unreleased lock after node restart

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3055?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3055: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done integrated. > Unreleased lock after node restart > ---------------------------------- > > Key: ISPN-3055 > URL: https://issues.jboss.org/browse/ISPN-3055 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.1.Final > Environment: Debian Squeeze Amd 64, JDK 1.6.0_32 > Reporter: Deyan Pandulev > Assignee: Pedro Ruivo > Labels: 5.2.x > Fix For: 5.3.0.Beta2, 5.3.0.Final > > Attachments: SimpleClusterRead.java, SimpleClusterWriter.java, simple_cluster_node1.xml, simple_cluster_node2.xml > > > Using dummy transaction manager I was able to produce locks that are not released. The same behavior can be reproduced with Glassfish AS 3.1.1 using its own TM. -- 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

11 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3063) Data Inconsistency when Recovery + syncCommitPhase=false

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3063?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-3063: ------------------------------------ I'm pretty sure the commit command could remove the transaction itself from the RecoveryManager. But Mircea is right: no matter how we remove the transaction from the RecoveryManager, we still can't guarantee that the transaction will be removed on all the owners in case of a crash by using only asynchronous calls. So it makes sense to disable this combination. > Data Inconsistency when Recovery + syncCommitPhase=false > -------------------------------------------------------- > > Key: ISPN-3063 > URL: https://issues.jboss.org/browse/ISPN-3063 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 5.2.5.Final, 5.3.0.Alpha1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Minor > Labels: recovery, transaction > > with syncCommitPhase=false, the CommitCommand is sent asynchronously. the TransactionCoordinator sends immediately the TxCompletionNotificationCommand that can be deliver first than the CommitCommand. The CommitCommand fails silently: > {code} > if (transaction == null) { > if (trace) log.tracef("Did not find a RemoteTransaction for %s", globalTx); > return invalidRemoteTxReturnValue(); > } > } > {code} > This bug affects the 5.3 and 5.2.5. I've made one test case to catch this bug: > 5.3 => https://github.com/pruivo/infinispan/blob/rec-async/core/src/test/java/or... > 5.2 => https://github.com/pruivo/infinispan/blob/rec-async-5.2/core/src/test/jav... > Note: this bug may happen if you use async communication (prepare in 1PC) > Note2: this may be related to https://issues.jboss.org/browse/ISPN-2719 > Possible solutions: > * do not allow to configure the cache with syncCommitPhase=false && recovery enabled; > * force syncCommitPhase=true when recovery is enabled; > * send the CommitCommand and the TxCompletionNotificationCommand as Regular Messages (they will be deliver in FIFO order) > Thanks to Diego Didona that spotted this bug. -- 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

11 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2013