January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3039) Add JCache quickstarts

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3039: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Add JCache quickstarts > ---------------------- > > Key: ISPN-3039 > URL: https://issues.jboss.org/browse/ISPN-3039 > Project: Infinispan > Issue Type: Task > Components: JCache > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.1.0.CR1 > > > Quickstarts should be added to https://github.com/infinispan/infinispan-quickstart so that users can get started quickly with JCache API. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3198) Allow multiple versions of entries to be stored

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3198?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3198: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Allow multiple versions of entries to be stored > ----------------------------------------------- > > Key: ISPN-3198 > URL: https://issues.jboss.org/browse/ISPN-3198 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Labels: leads, versioning > Fix For: 7.1.0.CR1 > > > Storing multiple versions of a given entry will pave the way for eventual consistency based on vector clocks as well as the ability for API-controlled versioning. > Will require that each entry is a structure that contains multiple actual entries ordered by version. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3159) Implementing SERIALIZABLE isolation level based on GMU

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3159?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3159: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Implementing SERIALIZABLE isolation level based on GMU > ------------------------------------------------------ > > Key: ISPN-3159 > URL: https://issues.jboss.org/browse/ISPN-3159 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.1.0.CR1 > > > Implementation based in GMU, a Cloud-TM project research (www.cloudtm.eu). > GMU is a muti-version scheme that provides Update Serializability. It allows the read-only transaction to proceed without blocking, but they can observe an old value (but always a consistent value). > This scheme relies in Vector Clock to manage the snapshots to read and the transaction dependencies in each node in the cluster. > Also, it is a genuine scheme, i.e., only the nodes involved in the transaction (that contains data read or write) are involved in the transaction commit. > A paper describing GMU can be found here: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=62... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3337) Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3337?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3337: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-3337 > URL: https://issues.jboss.org/browse/ISPN-3337 > Project: Infinispan > Issue Type: Feature Request > Components: Spring Integration > Reporter: Navin Surtani > Assignee: Gustavo Fernandes > Fix For: 7.1.0.CR1 > > > ISPN-3279 removed the ConfigurationOverrides and GlobalConfigurationOverrides classes in the Spring module. These classes contained older set() calls in order to override Cache configurations and given the way that programmatic Configuration currently works in Infinispan, that approach is not maintainable. > We hence need a clean way to provide (Global) Configuration beans as a newer, cleaner approach. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3273) Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3273: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1 > -------------------------------------------------------------------------- > > Key: ISPN-3273 > URL: https://issues.jboss.org/browse/ISPN-3273 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.1.0.CR1 > > Attachments: DistSyncFuncTest.java > > > When a write operation occurs causing a L1 invalidation, there is a boolean to say assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the originating node that caused this update. This works fine for the primary owner, however any additional backups think the origin is the primary owner and such send invalidations to possibly the real origin. > -This affects both tx and non tx caches. Tx caches that are sync don't see the problem since locking prevents the invalidation, however it causes an unneeded network roundtrip which can cause delay.- > Actually this only affects non-tx caches, as tx caches send the prepare/commit directly to the owner(s) instead of having it relayed. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3336) Extended Statistics check list

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3336?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3336: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Extended Statistics check list > ------------------------------ > > Key: ISPN-3336 > URL: https://issues.jboss.org/browse/ISPN-3336 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Labels: core > Fix For: 7.1.0.CR1 > > > * add documentation > * check for duplicate stats; > * check for not exposed statistics > * try to improve the code (reduce the number of access to the CHM) > * add tests to check if they are exported via JMX correctly > * failing test: OptimisticLockingTxClusterExtendedStatisticLogicTest.testWriteSkewOnNonOwner > * failing test: PessimisticLockingTxClusterExtendedStatisticLogicTest.testDeadlockOnNonOwnerWithRemoteTx -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3244) TopologyAwareSyncConsistentHashFactory should limit the number of segments per node

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3244: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > TopologyAwareSyncConsistentHashFactory should limit the number of segments per node > ----------------------------------------------------------------------------------- > > Key: ISPN-3244 > URL: https://issues.jboss.org/browse/ISPN-3244 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Dan Berindei > Fix For: 7.1.0.CR1 > > > Let's say we have a cluster with 5 nodes: A(r1), B(r2), C(r2), D(r3), E(r3) > TopologyAwareConsistentSyncHashFactory will spread the segments equally on each rack, meaning A will own 2x segments compared to the other nodes. > TopologyAwareConsistentHashFactory limits the maximum number per node, so that A owns just as many segments as the other nodes. With a slight limitation: the number of racks must be greater than numOwners, otherwise each rack must hold (at least) one copy of all the data. > TopologyAwareConsistentSyncHashFactory is a little random, so we can't distribute the data perfectly, but we can limit the number of segments on each node to something like 1.5x the average number of segments. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3223) HotRod 2.0 Client recieves stale toplogy view on instance leave

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3223?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3223: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > HotRod 2.0 Client recieves stale toplogy view on instance leave > --------------------------------------------------------------- > > Key: ISPN-3223 > URL: https://issues.jboss.org/browse/ISPN-3223 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 5.2.4.Final, 5.3.0.CR1, 7.0.0.Beta1 > Reporter: Takayoshi Kimura > Assignee: Galder Zamarreño > Fix For: 7.1.0.CR1 > > Attachments: hr-protocol-13.log, hr-protocol-20.log > > > When killed a HotRod server node, HotRod Clinet sometimes recieves a stale toplogy view which includes the dead node and uses it as a latest view. In this case the client keeps trying to connect that node and keeps failing. > Looks like the AbstractEncoder1x.generateTopologyResponse() takes care of node join but doesn't handle node leave: > {noformat} > if (!serverEndpointsMap.keySet.containsAll(cacheMembers)) { > {noformat} > For example, serverEndpointsMap.keySet is [A, B, C] and the actual cacheMembers is [A, B]. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3614) Add remote query quick start/demo

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3614?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3614: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Add remote query quick start/demo > --------------------------------- > > Key: ISPN-3614 > URL: https://issues.jboss.org/browse/ISPN-3614 > Project: Infinispan > Issue Type: Task > Components: Remote Querying > Reporter: Mircea Markus > Assignee: Adrian Nistor > Fix For: 7.1.0.CR1 > > > Should describe how the users: > - download the servers > - configure it (indexing ...) > - with sample domain model, how to write the marshallers, define the indexes using the RHQ plugin > - some code that connects to the server, adds and queries the data (mvn module?) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3602) Cache statistics update differently in library and Client-Server mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3602?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3602: ---------------------------------- Fix Version/s: 7.1.0.CR1 (was: 7.1.0.Beta1) > Cache statistics update differently in library and Client-Server mode > --------------------------------------------------------------------- > > Key: ISPN-3602 > URL: https://issues.jboss.org/browse/ISPN-3602 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.0.CR1 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Priority: Minor > Labels: dm > Fix For: 7.1.0.CR1 > > > When running jdg quickstart carmart ( https://github.com/infinispan/jdg-quickstart/tree/master/carmart ) I noticed interesting thing. > When calling replace() in library mode, the number of stores in cache statistics doesn't change whereas when calling in Client-Server mode, the number of stores increase by 1. > I went deeper into the code and I found out that in CacheMgmtInterceptor, where there are implemented methods for such statistics updates (like for put() ), there isn't implemented method for updating stats for replace() method, so the control flow is just passed. > I think it should be consistent, but I don't know which approach is intended, if either increase by 1 or leave it the same. > If increase is the answer than the solution is simple, implement CacheMgmtInterceptor.visitReplaceCommand(...) the same way as e.g. visitPutKeyValueCommand. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 3 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 January 2015