September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4664) Consider passing command retries flag to remote events

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4664?page=com.atlassian.jira.plugin.... ] Work on ISPN-4664 started by Galder Zamarreño. ---------------------------------------------- > Consider passing command retries flag to remote events > ------------------------------------------------------ > > Key: ISPN-4664 > URL: https://issues.jboss.org/browse/ISPN-4664 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > Cluster listeners have the ability to check whether an event is the result of a retried command. Even though HR clients are notified of failovers via the @ClientCacheFailover annotation, passing on this information could signal that an event is a duplicate or that another event was dropped and replaced (e.g. modified event replaced a created one). -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4599?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4599: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1134476|https://bugzilla.redhat.com/show_bug.cgi?id=1134476] from MODIFIED to ON_QA > InfinispanIndexManager locks held when primary node change > ---------------------------------------------------------- > > Key: ISPN-4599 > URL: https://issues.jboss.org/browse/ISPN-4599 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Affects Versions: 7.0.0.Alpha5 > Reporter: Gustavo Fernandes > Assignee: Sanne Grinovero > Priority: Critical > > 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.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4656) Test for GSSAPI authentication and LDAP authorization

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-4656?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-4656: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2842 > Test for GSSAPI authentication and LDAP authorization > ----------------------------------------------------- > > Key: ISPN-4656 > URL: https://issues.jboss.org/browse/ISPN-4656 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > > Implement a test which would verify client to server authentication over GSSAPI and client roles/authorization is loaded from LDAP server. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4666) Server core does not need getopt dependency any more

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4666?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4666: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2841 > Server core does not need getopt dependency any more > ---------------------------------------------------- > > Key: ISPN-4666 > URL: https://issues.jboss.org/browse/ISPN-4666 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 6.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > Ever since we start Infinispan Server via AS/WF base, there's no longer need for starting the server from command line, and hence, no longer need the command line argument processor dependency. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4569) Inserting into cache with indexing fails for XA transactions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4569: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1130493|https://bugzilla.redhat.com/show_bug.cgi?id=1130493] from MODIFIED to ON_QA > Inserting into cache with indexing fails for XA transactions > ------------------------------------------------------------ > > Key: ISPN-4569 > URL: https://issues.jboss.org/browse/ISPN-4569 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Transactions > Affects Versions: 7.0.0.Alpha5 > Reporter: Radim Vansa > Assignee: Dan Berindei > Fix For: 7.0.0.Beta1 > > > If I setup XA transactions in {{ClusteredQueryDslConditionsTest}} using > {code} > cacheCfg.transaction().transactionMode(TransactionMode.TRANSACTIONAL).useSynchronization(false); > {code} > the test fails. The reason is in deadlock while updating {{ScopedKey}} in __cluster_registry_cache__ : It seems that on originator we create transaction with modified inserted key and the {{ScopedKey}} for inserted class, and send it in two prepare commands to the other node. In the {{ScopedKey}}-prepare, the lock is acquired, but the regular prepare on the other node does not see it (it is not committed yet) and also tries to update this {{ScopedKey}} in __cluster_registry_cache__ . This fails with lock timeout, as the commit is waiting on the regular prepare to finish. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4688) Backport to 5.2.x for EAP 6.4

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4688?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-4688: ------------------------------- Priority: Critical (was: Major) > Backport to 5.2.x for EAP 6.4 > ----------------------------- > > Key: ISPN-4688 > URL: https://issues.jboss.org/browse/ISPN-4688 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 5.2.8.Final > Reporter: Paul Ferraro > Assignee: Dan Berindei > Priority: Critical > Fix For: 5.2.9.Final > > > Tracking jira for backporting fixes to 5.2.x for EAP 6.4. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4688) Backport to 5.2.x for EAP 6.4

by Paul Ferraro (JIRA)

Paul Ferraro created ISPN-4688: ---------------------------------- Summary: Backport to 5.2.x for EAP 6.4 Key: ISPN-4688 URL: https://issues.jboss.org/browse/ISPN-4688 Project: Infinispan Issue Type: Task Security Level: Public (Everyone can see) Components: Core Affects Versions: 5.2.8.Final Reporter: Paul Ferraro Assignee: Dan Berindei Fix For: 5.2.9.Final Tracking jira for backporting fixes to 5.2.x for EAP 6.4. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4396) DSL Query: right condition lost

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4396?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4396: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1108695|https://bugzilla.redhat.com/show_bug.cgi?id=1108695] from MODIFIED to ON_QA > DSL Query: right condition lost > ------------------------------- > > Key: ISPN-4396 > URL: https://issues.jboss.org/browse/ISPN-4396 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha4 > Reporter: Radim Vansa > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha5 > > > Condition created through query like this: > {code} > Query q = qf.from(User.class) > .not( > qf.having("name").eq("John") > .or(qf.having("surname").eq("Man"))) > .toBuilder().build(); > {code} > is not correctly parsed into JPQL query; it is > {code} > FROM org.infinispan.query.dsl.embedded.sample_domain_model.User _gen0 WHERE NOT (_gen0.name = 'John') > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4409) LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4409?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4409: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1108089|https://bugzilla.redhat.com/show_bug.cgi?id=1108089] from MODIFIED to ON_QA > LevelDBCacheStoreIT fails to initialise with com.arjuna.ats.arjuna.exceptions.FatalError > ---------------------------------------------------------------------------------------- > > Key: ISPN-4409 > URL: https://issues.jboss.org/browse/ISPN-4409 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > The LevelDBCacheStoreIT fails to start with an error resulting from initialising the server side cache marshaller. The way the cache manager is created is not correct. You might as well just use the same marshaller as for the client. > Even if you really need a cache's marshaller, you should get it via an injected cache rather than initialising a cache from scratch. > {code}com.arjuna.ats.arjuna.exceptions.FatalError: null > at com.arjuna.ats.internal.jts.ORBManager.getPOA(ORBManager.java:96) > at com.arjuna.ats.internal.jts.OTSImpleManager.<clinit>(OTSImpleManager.java:300) > at com.arjuna.ats.internal.jta.transaction.jts.TransactionImple.getTransaction(TransactionImple.java:1146) > at com.arjuna.ats.internal.jta.transaction.jts.TransactionManagerImple.getTransaction(TransactionManagerImple.java:69) > at org.infinispan.cache.impl.CacheImpl.getOngoingTransaction(CacheImpl.java:1414) > at org.infinispan.cache.impl.CacheImpl.getInvocationContextForRead(CacheImpl.java:592) > at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:474) > at org.infinispan.cache.impl.CacheImpl.keySet(CacheImpl.java:469) > at org.infinispan.registry.impl.ClusterRegistryImpl.keys(ClusterRegistryImpl.java:81) > at org.infinispan.query.remote.ProtobufMetadataManager.ensureInit(ProtobufMetadataManager.java:67) > at org.infinispan.query.remote.ProtobufMetadataManager.getSerializationContext(ProtobufMetadataManager.java:132) > at org.infinispan.query.remote.LifecycleManager.cacheStarting(LifecycleManager.java:114) > at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214) > at org.infinispan.cache.impl.CacheImpl.start(CacheImpl.java:699) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:573) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:528) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:408) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:381) > at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.getServerMarshaller(LevelDBCacheStoreIT.java:190) > at org.infinispan.server.test.cs.leveldb.LevelDBCacheStoreIT.<clinit>(LevelDBCacheStoreIT.java:67) > « Hide stacktrace{code} > The fix gets past this particular error but it still shows this afterwards: > {code}Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Server,name=HotRod,component=Transport{code} > Tristan is working on this... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-4605) Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4605?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4605: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1135924|https://bugzilla.redhat.com/show_bug.cgi?id=1135924] from MODIFIED to ON_QA > Race condition during Marshalling of Lucene Directory components would trigger nonsense during unmarshalling > ------------------------------------------------------------------------------------------------------------ > > Key: ISPN-4605 > URL: https://issues.jboss.org/browse/ISPN-4605 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Lucene Directory > Affects Versions: 7.0.0.Alpha5 > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 7.0.0.Beta1 > > > Some components in the Lucene Directory are highly concurrent, when these are marshalled we need to ensure a consistent snapshot is written to the byte stream. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 1 month

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014