September 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5743) SIFS.start() throws IllegalArgumentException: Negative position

by Radim Vansa (JIRA)

Radim Vansa created ISPN-5743: --------------------------------- Summary: SIFS.start() throws IllegalArgumentException: Negative position Key: ISPN-5743 URL: https://issues.jboss.org/browse/ISPN-5743 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 7.2.5.Final, 8.0.1.Final Reporter: Radim Vansa Assignee: Radim Vansa This can happen when a record about deletion of entry with the same key was read recently and was not applied into index. Fix is quite trivial, but this revealed a situation when an entry can be reincarnated during cache store startup - since we don't keep deleted entries in index, we can't see that an entry was deleted (don't know it's last seqId) if files are read in unlucky order. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5742) Add global persistent state path configuration

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-5742: ------------------------------------- Summary: Add global persistent state path configuration Key: ISPN-5742 URL: https://issues.jboss.org/browse/ISPN-5742 Project: Infinispan Issue Type: Sub-task Components: Configuration Reporter: Tristan Tarrant Assignee: Tristan Tarrant Fix For: 8.1.0.Final The GlobalConfiguration should be enhanced with global state persistence settings to define a location where state will be stored across restarts. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3926) The ClusterRegistry needs to be persistent

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3926?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-3926: ------------------------------------- Assignee: Tristan Tarrant > The ClusterRegistry needs to be persistent > ------------------------------------------ > > Key: ISPN-3926 > URL: https://issues.jboss.org/browse/ISPN-3926 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: Tristan Tarrant > > Several improvements suggested by Sanne: > - protobuf schemas should be persisted, hotrod topology info and security cache should not > - also for security I want to set lifetime properties -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5741) Null keys and values should not be allowed in RemoteCache

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-5741: -------------------------------------- Summary: Null keys and values should not be allowed in RemoteCache Key: ISPN-5741 URL: https://issues.jboss.org/browse/ISPN-5741 Project: Infinispan Issue Type: Bug Components: Remote Protocols Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 9.0.0.Final In the current code base, the current code is allowed and works for Remote Cache: {code} RemoteCache<?, ?> remoteCache = ... assertEquals(null, remoteCache.put(null, null)); assertEquals(null, remoteCache.get(null)); {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4046) New query dsl does not support isNull filters for non-string properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4046?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4046: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1261665, https://bugzilla.redhat.com/show_bug.cgi?id=1238869, https://bugzilla.redhat.com/show_bug.cgi?id=1247191 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1261665, https://bugzilla.redhat.com/show_bug.cgi?id=1238869) > New query dsl does not support isNull filters for non-string properties > ----------------------------------------------------------------------- > > Key: ISPN-4046 > URL: https://issues.jboss.org/browse/ISPN-4046 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.1.Final, 7.2.5.Final > > > String properties can be supported because of Hibernate Search null token, but HSearch only offers this for strings and not for other types. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4046) New query dsl does not support isNull filters for non-string properties

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4046?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4046: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1261665, https://bugzilla.redhat.com/show_bug.cgi?id=1238869 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1261665) > New query dsl does not support isNull filters for non-string properties > ----------------------------------------------------------------------- > > Key: ISPN-4046 > URL: https://issues.jboss.org/browse/ISPN-4046 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 6.0.1.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.0.1.Final, 7.2.5.Final > > > String properties can be supported because of Hibernate Search null token, but HSearch only offers this for strings and not for other types. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4423) Projections on an embedded entity are incorrectly allowed for remote queries

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4423?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4423: -------------------------------- Fix Version/s: 8.1.0.Final > Projections on an embedded entity are incorrectly allowed for remote queries > ---------------------------------------------------------------------------- > > Key: ISPN-4423 > URL: https://issues.jboss.org/browse/ISPN-4423 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.1.0.Final > > > Projecting a (complete) embedded entity should not be allowed. This validation works correctly for embedded dsl-based queries but does not work for remote queries (with lucene backend). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5691: ----------------------------------------------- Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1255783|https://bugzilla.redhat.com/show_bug.cgi?id=1255783] from ON_QA to VERIFIED > Server should enable writeSkew for some configurations by default > ----------------------------------------------------------------- > > Key: ISPN-5691 > URL: https://issues.jboss.org/browse/ISPN-5691 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final, 7.2.6.Final > > > By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655. > In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode. > Widlfly does enable write skew programmatically depending on the configuration: > {quote} > > hey, quick q: can you configure writeSkew on infinispan wildfly > config? > <pferraro> we always enable write skew for synchronous, optimistic, > repeatable-read caches, and disable otherwise > > pferraro: ah, you do it in the integration code? > <pferraro> yes > {quote} > We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ] Vlastimil Eliáš updated ISPN-4599: ---------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > InfinispanIndexManager locks held when primary node change > ---------------------------------------------------------- > > Key: ISPN-4599 > URL: https://issues.jboss.org/browse/ISPN-4599 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 7.0.0.Beta2 > > > Given the following configuration: > {code:xml} > <cache-container name="store" default-cache="default" statistics="true"> > <transport cluster="Infinispan-Query-Cluster"/> >  >  >  > <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true"> > <indexing index="LOCAL"> > <property name="hibernate.search.default.indexmanager"> > org.infinispan.query.indexmanager.InfinispanIndexManager > </property> > <property name="hibernate.search.default.directory_provider">infinispan</property> > </indexing> > </replicated-cache> > <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </distributed-cache> > <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > </cache-container> > {code} > Scenario: > - Start Node 1 > - Insert a few @Indexed objects in the cache > - Start Node 2 > - Insert a few @Indexed objects in the cache > Node 2 cannot acquire the locks to write and throws errors: > {code} > org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates > ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync! > Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException > ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f > {code} > During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking. > When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4599) InfinispanIndexManager locks held when primary node change

by Vlastimil Eliáš (JIRA)

[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ] Vlastimil Eliáš updated ISPN-4599: ---------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > InfinispanIndexManager locks held when primary node change > ---------------------------------------------------------- > > Key: ISPN-4599 > URL: https://issues.jboss.org/browse/ISPN-4599 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Remote Querying > Affects Versions: 7.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 7.0.0.Beta2 > > > Given the following configuration: > {code:xml} > <cache-container name="store" default-cache="default" statistics="true"> > <transport cluster="Infinispan-Query-Cluster"/> >  >  >  > <replicated-cache name="passivation" mode="SYNC" remote-timeout="20000" statistics="true"> > <indexing index="LOCAL"> > <property name="hibernate.search.default.indexmanager"> > org.infinispan.query.indexmanager.InfinispanIndexManager > </property> > <property name="hibernate.search.default.directory_provider">infinispan</property> > </indexing> > </replicated-cache> > <replicated-cache name="LuceneIndexesMetadata" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > <distributed-cache name="LuceneIndexesData" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </distributed-cache> > <replicated-cache name="LuceneIndexesLocking" mode="SYNC" remote-timeout="25000"> > <indexing index="NONE"/> > </replicated-cache> > </cache-container> > {code} > Scenario: > - Start Node 1 > - Insert a few @Indexed objects in the cache > - Start Node 2 > - Insert a few @Indexed objects in the cache > Node 2 cannot acquire the locks to write and throws errors: > {code} > org.hibernate.search.backend.impl.lucene.LuceneBackendQueueTask applyUpdates > ERROR: HSEARCH000072: Couldn't open the IndexWriter because of previous error: operation skipped, index ouf of sync! > Aug 01, 2014 4:48:23 PM org.hibernate.search.exception.impl.LogErrorHandler handleException > ERROR: HSEARCH000058: Exception occurred org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: org.infinispan.lucene.locking.BaseLuceneLock@2c1e889f > {code} > During the insertion on Node1, the InfinispanCommandsBackend elects Node 1 as the primary node (since it's the only one) and acquires the lock on the LuceneIndexesLocking. > When node 2 joins and the topology changes, the InfinispanCommandsBackend elects Node 2 as the primary node, but it fails to acquire the lock (held by Node 1) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 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 September 2015