November 2014 - infinispan-issues

[JBoss JIRA] (ISPN-2145) No descriptions for invalid jgroups configuration files

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2145?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2145: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > No descriptions for invalid jgroups configuration files > ------------------------------------------------------- > > Key: ISPN-2145 > URL: https://issues.jboss.org/browse/ISPN-2145 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.1.2.FINAL, 7.0.0.CR1 > Environment: Any > Reporter: Dmitry Udalov > Assignee: Tristan Tarrant > Fix For: 7.1.0.Beta1 > > > Can't find error's description for invalid jgroups configuration files. Shuffling elements of the file (why not!) makes it invalid, but log-files only report the existence of the error and you have to debug it to figure out the problem. It would be easier if the class JGroupsTransport also reports the exception, not just a generic message in blocks like > } catch (Exception e) { > log.errorCreatingChannelFromConfigFile(cfg); > throw new CacheException(e); > } > As a result log-file contains a lot of generic messages without explaining the problem, which in my case was quite helpful: > java.lang.Exception: events [GET_DIGEST SET_DIGEST FIND_INITIAL_MBRS FIND_ALL_VIEWS ] are required by GMS, but not provided by any of the protocols below it -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2141) Better configuration options for Infinispan Query

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2141?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2141: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Better configuration options for Infinispan Query > ------------------------------------------------- > > Key: ISPN-2141 > URL: https://issues.jboss.org/browse/ISPN-2141 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Sanne Grinovero > Assignee: Gustavo Fernandes > Fix For: 7.1.0.Beta1 > > > Rethink the configuration options for Query. > See also https://community.jboss.org/wiki/InfinispanQuery-DesignAndPlanning -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2939) Remove option for async Marshalling

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2939?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2939: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Remove option for async Marshalling > ----------------------------------- > > Key: ISPN-2939 > URL: https://issues.jboss.org/browse/ISPN-2939 > Project: Infinispan > Issue Type: Task > Components: Core > Reporter: Sanne Grinovero > Priority: Minor > Fix For: 7.1.0.Beta1 > > > Seems to introduce inconsistencies - and generally hard to figure out how to configure properly. -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2577) Silence SuspectExceptions

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-2577?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-2577: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > Silence SuspectExceptions > ------------------------- > > Key: ISPN-2577 > URL: https://issues.jboss.org/browse/ISPN-2577 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 5.2.0.Beta4, 6.0.0.Final > Reporter: Michal Linhard > Priority: Critical > Fix For: 7.1.0.Beta1 > > > There are lots of SuspectExceptions in resilience test run: > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > We managed to keep these under cover for 5.1.x branch. > This is of course a cosmetic problem, but it polutes the log with unnecessary ERRORs. > Parsed logs here: > http://www.qa.jboss.com/~mlinhard/test_results/run54-parsed/ -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3199) API to manipulate multiple versions of an entry

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3199?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3199: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > API to manipulate multiple versions of an entry > ----------------------------------------------- > > Key: ISPN-3199 > URL: https://issues.jboss.org/browse/ISPN-3199 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 5.3.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Labels: leads > Fix For: 7.1.0.Beta1 > > > In addition to the existing API, the following will be needed to allow user applications to directly control versioning. E.g., > {code} > put(K key, EntryVersion version); > get(K key, EntryVersion version); > getLatest(K key, EntryVersion upperBound); > evict(K key, EntryVersion upTo); > {code} -- This message was sent by Atlassian JIRA (v6.3.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3159?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3159: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3198?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3198: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3039?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3039: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3244: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

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

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3273: ------------------------------ Fix Version/s: 7.1.0.Beta1 (was: 7.1.0.Alpha1) > 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.Beta1 > > 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.8#6338)

10 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2014