January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2573) Make the default expiration flags in the HotRod client hidden from the API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2573?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-2573: ------------------------------------- Assignee: (was: Mircea Markus) > Make the default expiration flags in the HotRod client hidden from the API > -------------------------------------------------------------------------- > > Key: ISPN-2573 > URL: https://issues.jboss.org/browse/ISPN-2573 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: NadirX > > Also take the opportunity to introduce a DecoratedRemoteCache to avoid using ThreadLocal access for the flags -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4556) Bump JSR 107 Dependency

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4556?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4556: ------------------------------------- Assignee: (was: Mircea Markus) > Bump JSR 107 Dependency > ----------------------- > > Key: ISPN-4556 > URL: https://issues.jboss.org/browse/ISPN-4556 > Project: Infinispan > Issue Type: Task > Components: JCache > Affects Versions: 6.0.2.Final > Reporter: Ryan Dunckel > Priority: Minor > > Since JSR-107 has gone final, and Infinispan 7 hasn't been released yet, Infinispan 6 should bump its dep on javax.cache|cache-api from 1.0.0-PFD to 1.0.0. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4849) Offer ability to read the value in raw marshalled form in clustered listener filter and converter

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4849?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4849: ------------------------------------- Assignee: (was: Mircea Markus) > Offer ability to read the value in raw marshalled form in clustered listener filter and converter > ------------------------------------------------------------------------------------------------- > > Key: ISPN-4849 > URL: https://issues.jboss.org/browse/ISPN-4849 > Project: Infinispan > Issue Type: Feature Request > Reporter: Emmanuel Bernard > > To avoid the need to ship the value class to all the data grid classpath, it would be quite useful to ask to read the value as byte[] / marshalled form for the filter and converter part on each node involved (for a clustered listener). > For example, if the value is serialized as protobuf, an implementation could receive the byte[] of the protobuf and read the necessary properties without forcing a specific application .class file to be present. It also saves in unnecessary unmarshalling. Ideally a flag could be used @Listener(marshalled=false). > This issue might have been created (by Galder) but I cannot find it. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3064) Extend cache expiration notification to cache stores

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3064?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3064: ------------------------------------- Assignee: (was: Mircea Markus) > Extend cache expiration notification to cache stores > ---------------------------------------------------- > > Key: ISPN-3064 > URL: https://issues.jboss.org/browse/ISPN-3064 > Project: Infinispan > Issue Type: Feature Request > Components: Listeners, Loaders and Stores > Reporter: Galder Zamarreño > > Extend cache entry expiration notifications to situations where CacheStore instances, via purgeExpired(), expire data directly in the cache store. This is an extension of ISPN-694. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3550) Migrate Cassandra cache store to the 6.0 cachestore API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3550?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3550: ------------------------------------- Assignee: (was: Mircea Markus) > Migrate Cassandra cache store to the 6.0 cachestore API > -------------------------------------------------------- > > Key: ISPN-3550 > URL: https://issues.jboss.org/browse/ISPN-3550 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Mircea Markus > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3194) Create diagnostics dumping tool

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3194?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3194: ------------------------------------- Assignee: (was: Mircea Markus) > Create diagnostics dumping tool > ------------------------------- > > Key: ISPN-3194 > URL: https://issues.jboss.org/browse/ISPN-3194 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Labels: diagnostics > > A simple script that an end-user can run on an existing cluster, that will: > 1. Connect to a given node via JMX > 2. Get a list of all caches on all nodes > 3. Run JMX calls on each cache on each node to capture diagnostic data > 4. Serialise this data (maybe JSON?), zip it up. > This will allow end-users to share such stats for debugging and perf tuning. > Diagnostic data to be captured would include all JMX info on hit/miss ratio, RPC performance, transaction commit/rollback rates, config details, time budgeting info, etc. > This tool would require that JMX statistics are enabled and running for a while before the snapshot is captured. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4616) PartitionHandlingInterceptor should have special handling for DeltaCompositeKeys

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4616?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4616: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > PartitionHandlingInterceptor should have special handling for DeltaCompositeKeys > -------------------------------------------------------------------------------- > > Key: ISPN-4616 > URL: https://issues.jboss.org/browse/ISPN-4616 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Dan Berindei > Labels: partition_handling > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4587) Re-add old owners in the pending CH when a node leaves during rebalance

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4587?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4587: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Re-add old owners in the pending CH when a node leaves during rebalance > ----------------------------------------------------------------------- > > Key: ISPN-4587 > URL: https://issues.jboss.org/browse/ISPN-4587 > Project: Infinispan > Issue Type: Enhancement > Components: Core, State Transfer > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Priority: Minor > > Say we have a distributed cache \[A, B\] with {{numSegments = 1}} and {{numOwners = 2}}. The initial topology is _T_: currentCH = \{0: A B\}, pendingCH = null > C joins, and A starts a rebalance. The topology is now _T + 1_: currentCH = \{0: A B\}, pendingCH = \{0: A C\} > C now leaves, A updates the consistent hashes to remove it with a new topology _T + 2: currentCH = \{0: A B\}, pendingCH = \{0: A\} > A doesn't need to receive any data, so the rebalance ends and the pending CH is installed as the current CH in topology _T + 3_: currentCH = \{0: A\}, pendingCH = null > This algorithm is relatively easy to follow and implement, but it does result in reduced availability of the cache data. It would be better if topology _T + 2_ could re-add B as an owner in the pending CH. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4610) Implement total order for non-transactional caches

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4610?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4610: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Implement total order for non-transactional caches > -------------------------------------------------- > > Key: ISPN-4610 > URL: https://issues.jboss.org/browse/ISPN-4610 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > > Current locking algorithm in non-transactional caches needs a remote thread on the primary owner to block while replicating the update to the backup owner. The thread is also holding the lock for the key, so it's blocking other threads that want to write to the same key. When there is a lot of contention, this can exhaust the remote executor thread pool and cause lock timeouts. > TO was designed with high contention in mind, and it doesn't block threads to acquire locks. So it should handle this much better. > An alternative solution would be the locking rework in ISPN-2849. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[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: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Too many OutdatedTopologyExceptions in non-transactional caches > --------------------------------------------------------------- > > Key: ISPN-4586 > URL: https://issues.jboss.org/browse/ISPN-4586 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Labels: 7.0, performance > > 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)

11 years, 2 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