September 2019 - infinispan-issues

[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2575: -------------------------------- Assignee: Adrian Nistor (was: Sanne Grinovero) > KeyTransformer registration is required on all nodes of the cluster, in case of custom keys > ------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

5 days, 22 hours

2
1
0 / 0

[JBoss JIRA] (ISPN-10668) Expiration reaper should log the number of entries removed

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10668?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10668: ------------------------------ Fix Version/s: 10.0.0.CR3 9.4.17.Final > Expiration reaper should log the number of entries removed > ---------------------------------------------------------- > > Key: ISPN-10668 > URL: https://issues.jboss.org/browse/ISPN-10668 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > Fix For: 10.0.0.CR3, 9.4.17.Final > > > To track the expiration process the reaper should log messages which show the number of expired and removed entry per cache additional to the start/stop and duration which can be seen at this point -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10696) Cluster Expiration reaper limits parallel expirations too much

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10696?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10696: ------------------------------ Fix Version/s: 10.0.0.CR3 (was: 10.0.0.Final) > Cluster Expiration reaper limits parallel expirations too much > -------------------------------------------------------------- > > Key: ISPN-10696 > URL: https://issues.jboss.org/browse/ISPN-10696 > Project: Infinispan > Issue Type: Bug > Affects Versions: 10.0.0.CR2 > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.CR3, 9.4.17.Final > > > The expiration reaper today currently limits the expiration to only allow 5 pending expiration commands at once. It also doesn't submit more expirations until those 5 complete. We should do the following changes: > # Increase the limit, possibly to 100? > # Allow for extra expiration commands to be invoked as the others are complete, instead of waiting for all of them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10668) Expiration reaper should log the number of entries removed

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10668?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10668: ------------------------------ Status: Open (was: New) > Expiration reaper should log the number of entries removed > ---------------------------------------------------------- > > Key: ISPN-10668 > URL: https://issues.jboss.org/browse/ISPN-10668 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > To track the expiration process the reaper should log messages which show the number of expired and removed entry per cache additional to the start/stop and duration which can be seen at this point -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10668) Expiration reaper should log the number of entries removed

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10668?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10668: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7374 > Expiration reaper should log the number of entries removed > ---------------------------------------------------------- > > Key: ISPN-10668 > URL: https://issues.jboss.org/browse/ISPN-10668 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > To track the expiration process the reaper should log messages which show the number of expired and removed entry per cache additional to the start/stop and duration which can be seen at this point -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10696) Cluster Expiration reaper limits parallel expirations too much

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10696?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10696: ------------------------------ Status: Open (was: New) > Cluster Expiration reaper limits parallel expirations too much > -------------------------------------------------------------- > > Key: ISPN-10696 > URL: https://issues.jboss.org/browse/ISPN-10696 > Project: Infinispan > Issue Type: Bug > Affects Versions: 10.0.0.CR2 > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > The expiration reaper today currently limits the expiration to only allow 5 pending expiration commands at once. It also doesn't submit more expirations until those 5 complete. We should do the following changes: > # Increase the limit, possibly to 100? > # Allow for extra expiration commands to be invoked as the others are complete, instead of waiting for all of them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10696) Cluster Expiration reaper limits parallel expirations too much

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10696?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10696: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/7374 > Cluster Expiration reaper limits parallel expirations too much > -------------------------------------------------------------- > > Key: ISPN-10696 > URL: https://issues.jboss.org/browse/ISPN-10696 > Project: Infinispan > Issue Type: Bug > Affects Versions: 10.0.0.CR2 > Reporter: Will Burns > Priority: Major > Fix For: 10.0.0.Final, 9.4.17.Final > > > The expiration reaper today currently limits the expiration to only allow 5 pending expiration commands at once. It also doesn't submit more expirations until those 5 complete. We should do the following changes: > # Increase the limit, possibly to 100? > # Allow for extra expiration commands to be invoked as the others are complete, instead of waiting for all of them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10668) Expiration reaper should log the number of entries removed

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10668?page=com.atlassian.jira.plugin... ] Will Burns updated ISPN-10668: ------------------------------ Summary: Expiration reaper should log the number of entries removed (was: Expiration reaper should log (DEBUG?) the number of entries expired and removed) > Expiration reaper should log the number of entries removed > ---------------------------------------------------------- > > Key: ISPN-10668 > URL: https://issues.jboss.org/browse/ISPN-10668 > Project: Infinispan > Issue Type: Enhancement > Reporter: Wolf-Dieter Fink > Assignee: Will Burns > Priority: Major > > To track the expiration process the reaper should log messages which show the number of expired and removed entry per cache additional to the start/stop and duration which can be seen at this point -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10696) Cluster Expiration reaper limits parallel expirations too much

by Will Burns (Jira)

Will Burns created ISPN-10696: --------------------------------- Summary: Cluster Expiration reaper limits parallel expirations too much Key: ISPN-10696 URL: https://issues.jboss.org/browse/ISPN-10696 Project: Infinispan Issue Type: Bug Affects Versions: 10.0.0.CR2 Reporter: Will Burns Fix For: 10.0.0.Final, 9.4.17.Final The expiration reaper today currently limits the expiration to only allow 5 pending expiration commands at once. It also doesn't submit more expirations until those 5 complete. We should do the following changes: # Increase the limit, possibly to 100? # Allow for extra expiration commands to be invoked as the others are complete, instead of waiting for all of them. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10669) MurmurHash3 should have a special case for WrappedBytes

by Will Burns (Jira)

[ https://issues.jboss.org/browse/ISPN-10669?page=com.atlassian.jira.plugin... ] Will Burns commented on ISPN-10669: ----------------------------------- Just to note, only WrappedBytes is used as key. The other implementation `ProtobufValueWrapper` is only used as a value and thus isn't hashed using murmur hash. > MurmurHash3 should have a special case for WrappedBytes > ------------------------------------------------------- > > Key: ISPN-10669 > URL: https://issues.jboss.org/browse/ISPN-10669 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 10.0.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Major > Fix For: 10.0.0.CR3 > > > {{MurmurHash3.hashCode(Object)}} has a special case for {{WrappedBytesArray}}, but not for other implementations of {{WrappedBytes}} like {{ProtobufValueWrapper}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2019