January 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4140) Clear command doesn't acquire any remote locks in pessimistic mode

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4140?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4140: ------------------------------------- Assignee: Pedro Ruivo > Clear command doesn't acquire any remote locks in pessimistic mode > ------------------------------------------------------------------ > > Key: ISPN-4140 > URL: https://issues.jboss.org/browse/ISPN-4140 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 7.1.0.CR1 > > > This is related to ISPN-2530. The 1-phase prepare command is now sent remotely, but it doesn't acquire any locks. The clear command doesn't trigger any remote LockControlCommands either. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4175) Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4175?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4175: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Initialisation of remote query module fails randomly due to ClusterRegistry not bein initialised > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4175 > URL: https://issues.jboss.org/browse/ISPN-4175 > Project: Infinispan > Issue Type: Bug > Components: Remote Querying > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > {code} > 11:47:01,852 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.infinispan.clustered.memcachedCache: org.jboss.msc.service.StartException in service jboss.infinispan.clustered.memcachedCache: Failed to start service > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > Caused by: org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:241) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:546) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:517) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:399) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:413) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) > at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) > at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.4.GA-redhat-1.jar:1.0.4.GA-redhat-1] > ... 3 more > Caused by: org.infinispan.commons.CacheConfigurationException: No registered default factory for component 'interface org.infinispan.registry.ClusterRegistry' found!. To get more detail set the system property infinispan.debugDependencies to true > at org.infinispan.factories.AbstractComponentRegistry.throwStackAwareConfigurationException(AbstractComponentRegistry.java:884) > at org.infinispan.factories.AbstractComponentRegistry.getFactory(AbstractComponentRegistry.java:299) > at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:270) > at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227) > at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65) > at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797) > at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156) > at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:148) > at org.infinispan.query.remote.LifecycleManager.initProtobufMetadataManager(LifecycleManager.java:56) > at org.infinispan.query.remote.LifecycleManager.cacheManagerStarted(LifecycleManager.java:70) > at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:228) > ... 12 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4167) DummyBaseTransactionManager doesn't clean up when rollback fails

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4167?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4167: ------------------------------------- Assignee: Pedro Ruivo > DummyBaseTransactionManager doesn't clean up when rollback fails > ---------------------------------------------------------------- > > Key: ISPN-4167 > URL: https://issues.jboss.org/browse/ISPN-4167 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Fix For: 7.1.0.CR1 > > > If the rollback fails, the thread local holding the current transaction is not cleared, and it becomes impossible to start a new transaction on the same thread. > One way this can happen is when Infinispan registers as a XA transaction, but DummyTransactionManager is not configured to use XA Xids: > {noformat} > 12:47:57,169 ERROR (testng-ReplicationExceptionTest:) [DummyTransaction] ISPN000098: Exception while rollback > java.lang.UnsupportedOperationException > at org.infinispan.transaction.tm.DummyNoXaXid.getBranchQualifier(DummyNoXaXid.java:30) > at org.infinispan.transaction.xa.recovery.SerializableXid.<init>(SerializableXid.java:37) > at org.infinispan.transaction.xa.TransactionXaAdapter.convertXid(TransactionXaAdapter.java:251) > at org.infinispan.transaction.xa.TransactionXaAdapter.rollback(TransactionXaAdapter.java:122) > at org.infinispan.transaction.tm.DummyTransaction.runRollback(DummyTransaction.java:281) > at org.infinispan.transaction.tm.DummyTransaction.rollback(DummyTransaction.java:88) > at org.infinispan.transaction.tm.DummyBaseTransactionManager.rollback(DummyBaseTransactionManager.java:104) > at org.infinispan.CacheImpl.tryRollback(CacheImpl.java:1442) > at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1418) > at org.infinispan.CacheImpl.putInternal(CacheImpl.java:894) > at org.infinispan.CacheImpl.put(CacheImpl.java:886) > at org.infinispan.CacheImpl.put(CacheImpl.java:1461) > at org.infinispan.CacheImpl.put(CacheImpl.java:225) > at org.infinispan.tx.synchronisation.ReplicationExceptionTest.testSyncReplTimeout(ReplicationExceptionTest.java:54) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes resolved ISPN-4650. ------------------------------------- Resolution: Done This was addressed by ISPN-5103, where every indexing operation is being done using the more efficient ByTermDeleteDelegate/ByTermUpdateDelegate > MassIndexer should not use UpdateDocument when adding to Lucene > --------------------------------------------------------------- > > Key: ISPN-4650 > URL: https://issues.jboss.org/browse/ISPN-4650 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.1.0.Final > > > The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend. > Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. > Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: > * indexing 50k documents brings down the indexing time from 195s to 33s > * indexing 200k documents brings down the indexing time from 600s to 55s -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4650) MassIndexer should not use UpdateDocument when adding to Lucene

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4650?page=com.atlassian.jira.plugin.... ] Work on ISPN-4650 started by Gustavo Fernandes. ----------------------------------------------- > MassIndexer should not use UpdateDocument when adding to Lucene > --------------------------------------------------------------- > > Key: ISPN-4650 > URL: https://issues.jboss.org/browse/ISPN-4650 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.1.0.Final > > > The MassIndexer currently causes a Delete plus and Add operation to hibernate search backend. > Lucene buffers those deletes queries and during merge it tries to 'apply' those deletes wasting a massive amount of time doing seeks and queries unnecessarily. > Since the mass indexer wipes the index at the beginning, it should simply issue an add operation (or at least rely on Lucene atomic IndexWriter.updateDocument). Performance wise this make a huge difference: > * indexing 50k documents brings down the indexing time from 195s to 33s > * indexing 200k documents brings down the indexing time from 600s to 55s -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-4176: ------------------------------------- Assignee: Pedro Ruivo > Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4176 > URL: https://issues.jboss.org/browse/ISPN-4176 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > > {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible. > We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well. > But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4176) Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-4176: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > Forcing a commit via recovery RecoveryAdminOperations may create a duplicate GlobalTransaction > ---------------------------------------------------------------------------------------------- > > Key: ISPN-4176 > URL: https://issues.jboss.org/browse/ISPN-4176 > Project: Infinispan > Issue Type: Bug > Components: Core, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > > {{RecoveryManagerImpl.forceTransactionCompletion()}} modifies the {{GlobalTransaction.address}} of the transaction being committed so that the local node is the originator. But the {{GlobalTransaction.id}} stays the same, we could have two transactions with the same {{GlobalTransaction}} - which shouldn't be possible. > We can't remove the code that changes the {{GlobalTransaction.address}}, because we use it as the originator in other parts of the code. So the only option is to generate a new id as well. > But there is another problem: RecoveryAwareTransactionTable.cleanupStaleTransactions() doesn't release the locks acquired by that transaction on the primary node. So forcing a commit with a different GlobalTransaction will not be able to acquire the locks that were held by the original transaction. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3908) Security (Authentication, Authorization, Audit, Encryption)

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3908?page=com.atlassian.jira.plugin.... ] Tristan Tarrant resolved ISPN-3908. ----------------------------------- Assignee: Tristan Tarrant Fix Version/s: 7.0.0.Final (was: 7.1.0.CR1) Resolution: Done Aside from fine-grained authorization this is complete > Security (Authentication, Authorization, Audit, Encryption) > ----------------------------------------------------------- > > Key: ISPN-3908 > URL: https://issues.jboss.org/browse/ISPN-3908 > Project: Infinispan > Issue Type: Task > Components: Core, Remote Protocols, Security, Server > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Critical > Labels: roadmap > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3928) The ClusterRegistry API needs extending to allow put of mortal entries

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3928?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3928: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > The ClusterRegistry API needs extending to allow put of mortal entries > ---------------------------------------------------------------------- > > Key: ISPN-3928 > URL: https://issues.jboss.org/browse/ISPN-3928 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Tristan Tarrant > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3927: ---------------------------------- Fix Version/s: (was: 7.1.0.CR1) > rethinking ISPN transactions > ---------------------------- > > Key: ISPN-3927 > URL: https://issues.jboss.org/browse/ISPN-3927 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: Ion Savin > Labels: roadmap > > Umbrella JIRA for several transaction related improvements: > 1. Async options for commit/rollback > - they don't really make sense as a user you don't get any guarantee on the status of the transaction > - they complicate the code significantly > - I think they should be removed > 2. READ_COMMITTED > - it has the same performance as REPEATABLE_READ, but offers less guarantees. > - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator > - I think it should be removed > 3. Optimistic tx without Write Skew Check (WSC) > - well, without WSC the transactions are not optimistic by definition > - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee > - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it) > - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such > 4. Remove 1PC option > - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing > [1] http://markmail.org/thread/a7fjko4dyejxqgdy > [2] https://github.com/infinispan/infinispan/pull/2177 > [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv > [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 2015