January 2019 - infinispan-issues - Jboss List Archives

[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.7.Final (was: 9.4.6.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.7.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, 2 months

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.7.Final (was: 9.4.6.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.7.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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9610) Expose PersistenceManager availability via JMX

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9610?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9610: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Expose PersistenceManager availability via JMX > ---------------------------------------------- > > Key: ISPN-9610 > URL: https://issues.jboss.org/browse/ISPN-9610 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 9.4.7.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6011: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > ClassCastException in CDI generated keys for JCache > --------------------------------------------------- > > Key: ISPN-6011 > URL: https://issues.jboss.org/browse/ISPN-6011 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 9.4.7.Final > > > When using JCache-annotations the DefaultCacheKeyGenerator exclusively looks at parameter values to form the cache key. Therefore it will be very likely that collissions occur (resulting in difficult to find ClassCastExceptions). The provided patch uses the method- and class names as additionally values to make the cache key more unique. > Might also add that I am aware that by spec this should not be an issue when no cachename is given (as it should generate a cache using the class-name), but when a cache name is given collissions may occur. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6015) Query DSL should support groupBy for multi-valued properties

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6015?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6015: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Query DSL should support groupBy for multi-valued properties > ------------------------------------------------------------ > > Key: ISPN-6015 > URL: https://issues.jboss.org/browse/ISPN-6015 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 9.4.7.Final > > > If a groupBy property is multivalued the entity will belong to multiple groups, one for each distinct value. > Current implementation in 8.0.x and 8.1.x does not allow this and instead of providing invalid results grouping by multivalued property was disallowed (see ISPN-6008). -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6041) Remote Listeners: Client event reader thread reports EOF as error

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6041?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6041: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Remote Listeners: Client event reader thread reports EOF as error > ----------------------------------------------------------------- > > Key: ISPN-6041 > URL: https://issues.jboss.org/browse/ISPN-6041 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Priority: Minor > Fix For: 9.4.7.Final > > > {noformat} > 14:02:14,904 ERROR (Client-Listener-87aa07aee56d43e1) [ClientListenerNotifier] ISPN004043: Unrecoverable error reading event from server /127.0.0.1:15530, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException: End of stream reached! > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:198) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:305) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:147) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:252) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > {noformat} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9657) Multimap jar is not OSGi compliant

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9657?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9657: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Multimap jar is not OSGi compliant > ---------------------------------- > > Key: ISPN-9657 > URL: https://issues.jboss.org/browse/ISPN-9657 > Project: Infinispan > Issue Type: Bug > Components: Multimap > Affects Versions: 9.4.0.Final > Reporter: Alain Picard > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta1, 9.4.7.Final > > > Due to issues related to using the embedded jar (see [here|https://developer.jboss.org/message/986042#986042], when switching to individual jars, the multimap jar (infinispan-multimap-9.4.0.Final.jar) doesn't provide a valid OSGi manifest. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

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.7.Final (was: 9.4.6.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.7.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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9677) Non-transactional queries don't update the query cache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9677?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9677: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Non-transactional queries don't update the query cache > ------------------------------------------------------ > > Key: ISPN-9677 > URL: https://issues.jboss.org/browse/ISPN-9677 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.4.1.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Priority: Major > Fix For: 10.0.0.Alpha1, 9.4.7.Final > > > This is affecting the Hibernate second-level cache simple tutorials where queries are executed outside transactions. > The problem is that the new integration for the query results (result of ISPN-9075) does not verify if there's an on-going transaction before registering a transaction completed synchronization where the query cache is updated. > As a result, when a non-transactional query happens, the transaction synchronization callback does not happen and the query cache is not updated. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6084) Continuous query should reject queries with orderBy

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-6084?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6084: ---------------------------------- Fix Version/s: 9.4.7.Final (was: 9.4.6.Final) > Continuous query should reject queries with orderBy > --------------------------------------------------- > > Key: ISPN-6084 > URL: https://issues.jboss.org/browse/ISPN-6084 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 8.1.0.Final, 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > Fix For: 9.4.7.Final > > > Current behaviour it that orderBy is silently ignored. Disallowing this and throwing an exception would be preferable. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 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 2019