February 2019 - infinispan-issues

[JBoss JIRA] (ISPN-9587) Key Transformer registration via config

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9587?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9587: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Key Transformer registration via config > --------------------------------------- > > Key: ISPN-9587 > URL: https://issues.jboss.org/browse/ISPN-9587 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.8.Final > > > Under indexing config element: > {code} > <key-transformers> > <key-transformer key="org.infinispan.query.test.CustomKey" transformer="org.infinispan.query.test.CustomTransformer"/> > </key-transformers> > {code} > and also via the config builder API. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9582) Lifespan/MaxIdle = 0 from Hot Rod behaviour is inconsistent with embedded

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9582?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9582: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Lifespan/MaxIdle = 0 from Hot Rod behaviour is inconsistent with embedded > ------------------------------------------------------------------------- > > Key: ISPN-9582 > URL: https://issues.jboss.org/browse/ISPN-9582 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.4.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.8.Final > > > In embedded mode, specifying 0 for lifespan or maxIdle results in immediate expiration. > In Hot Rod, however, 0 results in the entry using the default server-side expiration. This was done in order to not introduce a protocol change at the time. > The 2.2 protocol introduced timeunit support with special values for default and infinity. > We should therefore not override a user-specified value of 0 with "default". -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9578) Move HR wire docs to contributing guide

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9578?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9578: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Move HR wire docs to contributing guide > --------------------------------------- > > Key: ISPN-9578 > URL: https://issues.jboss.org/browse/ISPN-9578 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 9.4.0.CR3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 9.4.8.Final > > > The Hot Rod wire protocol has no place in the user guide. It should be moved to the contributing guide. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9564) Align pom.xml order and versions

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9564?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9564: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Align pom.xml order and versions > -------------------------------- > > Key: ISPN-9564 > URL: https://issues.jboss.org/browse/ISPN-9564 > Project: Infinispan > Issue Type: Enhancement > Components: Build > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Major > Fix For: 9.4.8.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9555) ComponentRegistry should enforce that registered components implement the interface/contract

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9555?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9555: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > ComponentRegistry should enforce that registered components implement the interface/contract > -------------------------------------------------------------------------------------------- > > Key: ISPN-9555 > URL: https://issues.jboss.org/browse/ISPN-9555 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Adrian Nistor > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.8.Final > > > ComponentRegistry.registerComponent(impl, interface) does not currently check that the impl really is assignable to the interface. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9541) Module initialization is not thread-safe

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9541?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9541: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Module initialization is not thread-safe > ---------------------------------------- > > Key: ISPN-9541 > URL: https://issues.jboss.org/browse/ISPN-9541 > Project: Infinispan > Issue Type: Bug > Components: Core, Server > Affects Versions: 9.4.0.CR3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 9.4.8.Final > > > In my ISPN-9127 fix I created a {{BasicComponentRegistry}} interface that represents a mostly-read-only collection of components. It has {{replaceComponent()}} method and a {{rewire()}} method for testing purposes, but it turns out modules were also relying on the ability to replace existing components in order to work. > Replacing global components is normally safe during the {{ModuleLifecycle.cacheManagerStarting()}}, because none of the components are started yet, so when a component starts later we can still start its dependencies first. But because some modules starts some global components, e.g. by calling {{manager.getCache(name)}}, that assumption breaks. > The {{infinispan-server-event-logger}} module is a bit more sneaky: it doesn't replace a component, instead it replaces the actual implementation of the event logger in the {{EventLogManager}} component. Events that happen before the module's {{cacheManagerStarting()}} or after {{cacheManagerStopping()}} will be silently dropped from the persistent event log. > I am investigating making the module a factory of factories. Instead of having a monolitic {{cacheManagerStarting()}} method, it could define a set of components that it can create, and a set of components that should be started before the cache manager is "running". We probably need a way to depend on other modules as well, maybe reusing the {{@Inject}} and {{@ComponentName}} annotations. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9443) Fail when single region is accessed with multiple strategies

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9443: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Fail when single region is accessed with multiple strategies > ------------------------------------------------------------ > > Key: ISPN-9443 > URL: https://issues.jboss.org/browse/ISPN-9443 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.3.1.Final > Reporter: Radim Vansa > Priority: Major > Fix For: 9.4.8.Final > > > When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on. > Example: > {code} > @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item") > public static class NonStrictReadWriteVersionedCacheableItem { ... } > @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item") > public static class ReadWriteVersionedCacheableItem { ... } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9886) Use UFC_NB and MFC_NB in default embedded configurations

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9886?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9886: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Use UFC_NB and MFC_NB in default embedded configurations > -------------------------------------------------------- > > Key: ISPN-9886 > URL: https://issues.jboss.org/browse/ISPN-9886 > Project: Infinispan > Issue Type: Task > Components: Configuration > Affects Versions: 10.0.0.Alpha2, 9.4.5.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.8.Final > > > Once properly configured, UFC_NB and MFC_NB are just as fast as their blocking siblings (ISPN-9828). We should use the non-blocking variants everywhere to simplify configuration. > We should include UFC_NB even in the TCP configuration, to prevent async messages from overwhelming the receiver (JGRP-2301). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9699) Cluster member owning no data

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9699?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9699: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Cluster member owning no data > ----------------------------- > > Key: ISPN-9699 > URL: https://issues.jboss.org/browse/ISPN-9699 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Affects Versions: 9.4.1.Final > Reporter: Thomas Segismont > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.8.Final > > > Currently, you can set {{capacity-factor}} to zero on a cache if you don't want a node to own any segment. > If you want a node to own no data at all, you could set this property on all declared caches. But this wouldn't work for internal caches anyway (locks, counters). > It would be nice to have a global switch. > This would be useful when your app needs to be a cluster member for discovery/membership but is deployed mostly for processing. Indeed, when such nodes are added/removed from the cluster: > * there would be no data loss > * the cluster would be back in healthy state faster as no data would be moved around. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9726) Document max clause property on boolean query

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9726?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9726: ---------------------------------- Fix Version/s: 9.4.8.Final (was: 9.4.7.Final) > Document max clause property on boolean query > --------------------------------------------- > > Key: ISPN-9726 > URL: https://issues.jboss.org/browse/ISPN-9726 > Project: Infinispan > Issue Type: Task > Components: Embedded Querying, Remote Querying > Affects Versions: 10.0.0.Alpha1 > Reporter: Katia Aresti > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.8.Final > > > Document the ability to override org.apache.lucene.search.BooleanQuery.maxClauseCount using infinispan.query.lucene.max-boolean-clauses JVM system property. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2019