October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3593) Disallow storing a Lucene index when storeAsBinary is enabled

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3593?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3593: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks! > Disallow storing a Lucene index when storeAsBinary is enabled > ------------------------------------------------------------- > > Key: ISPN-3593 > URL: https://issues.jboss.org/browse/ISPN-3593 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Affects Versions: 6.0.0.CR1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final > > > As discussed on the mailing list, this configuration doesn't make sense for the Lucene Directory and can cause trouble. > Let's add some validation to throw a runtime exception to disallow this configuration when a Directory is created on a cache. > Could probably be done in a very similar way as: > https://github.com/infinispan/infinispan/commit/2f6447e197abe2e9e62c796ab... -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3588) CacheManager.startCaches ignores exceptions if cache fails to start

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3588?page=com.atlassian.jira.plugin.... ] Pedro Ruivo reassigned ISPN-3588: --------------------------------- Assignee: Pedro Ruivo (was: Mircea Markus) > CacheManager.startCaches ignores exceptions if cache fails to start > ------------------------------------------------------------------- > > Key: ISPN-3588 > URL: https://issues.jboss.org/browse/ISPN-3588 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final, 6.1.0.Final > > > {code}startCaches(){code} creates a thread for each cache name and if a cache fails to start, the invoker is never notified and the start count down latch is released. > the result is the application using the cache without be aware of the fail. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3588) CacheManager.startCaches ignores exceptions if cache fails to start

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3588?page=com.atlassian.jira.plugin.... ] Work on ISPN-3588 started by Pedro Ruivo. > CacheManager.startCaches ignores exceptions if cache fails to start > ------------------------------------------------------------------- > > Key: ISPN-3588 > URL: https://issues.jboss.org/browse/ISPN-3588 > Project: Infinispan > Issue Type: Bug > Affects Versions: 6.0.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final, 6.1.0.Final > > > {code}startCaches(){code} creates a thread for each cache name and if a cache fails to start, the invoker is never notified and the start count down latch is released. > the result is the application using the cache without be aware of the fail. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3365) org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3365?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3365: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 987927|https://bugzilla.redhat.com/show_bug.cgi?id=987927] The tests also fail for Open JDK6 && RHEL6_x64 environment. > org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored fails with AssertionError > -------------------------------------------------------------------------------------- > > Key: ISPN-3365 > URL: https://issues.jboss.org/browse/ISPN-3365 > Project: Infinispan > Issue Type: Bug > Components: Lucene Directory > Affects Versions: 6.0.0.Alpha1 > Environment: RHEL5_x86_64, IBMJDK1.7 > Reporter: Vitalii Chepeliuk > Assignee: Sanne Grinovero > Labels: testsuite_stability > Attachments: infinispan-lucene-v3.log.zip > > > Stacktrace > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) > at org.infinispan.lucene.DatabaseStoredIndexTest.indexWasStored(DatabaseStoredIndexTest.java:111) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:88) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) > at java.lang.reflect.Method.invoke(Method.java:613) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111) > at org.testng.TestRunner.privateRun(TestRunner.java:767) > at org.testng.TestRunner.run(TestRunner.java:617) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:334) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:37) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368) > at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:345) > at java.util.concurrent.FutureTask.run(FutureTask.java:177) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1156) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:626) > at java.lang.Thread.run(Thread.java:780) > Standard Output > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdt|RL|testing index > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.tis|RL|testing index > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:segments_4|RL|testing index > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.nrm|RL|testing index > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.prx|RL|testing index > Key found in store, shouldn't have persisted this or should have cleaned up all readlocks on directory close:_3.fdx|RL|testing index > [testng-DatabaseStoredIndexTest] Test indexWasStored(org.infinispan.lucene.DatabaseStoredIndexTest) failed. > Add link to jenkins job https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e... -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3599: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1016054|https://bugzilla.redhat.com/show_bug.cgi?id=1016054] During state-transfer in tx cache, the node can receive CommitCommand from other node. After the node gets transaction data for affected segments, it creates the transaction with missingLookedUpEntries=true and the CommitCommand can be executed. In this command's perform(...) the transaction is first marked as completed, then it enters the interceptor chain. There, the PrepareCommand is created in StateTransferInterceptor.visitCommitCommand but after this is processed the TxInterceptor finds out that the transaction is already completed and executes RollbackCommand, clearing locks etc. Nevertheless, StateTransferInterceptor executes the initial CommitCommand afterwards. I suspect that this may be executed without the locks held. Anyway, it is not correct to execute both commit and rollback on the same transaction. > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3599: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016054 > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) Replayed CommitCommand executes rollback and then commit

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3599: --------------------------------- Summary: Replayed CommitCommand executes rollback and then commit Key: ISPN-3599 URL: https://issues.jboss.org/browse/ISPN-3599 Project: Infinispan Issue Type: Bug Components: State transfer, Transactions Affects Versions: 6.0.0.CR1 Reporter: Radim Vansa Assignee: Mircea Markus Priority: Critical During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3599) CommitCommand with replayed PrepareCommand executes rollback and then commit

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-3599?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-3599: ------------------------------ Summary: CommitCommand with replayed PrepareCommand executes rollback and then commit (was: Replayed CommitCommand executes rollback and then commit) > CommitCommand with replayed PrepareCommand executes rollback and then commit > ---------------------------------------------------------------------------- > > Key: ISPN-3599 > URL: https://issues.jboss.org/browse/ISPN-3599 > Project: Infinispan > Issue Type: Bug > Components: State transfer, Transactions > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: Mircea Markus > Priority: Critical > > During state-transfer in tx cache, the node can receive {{CommitCommand}} from other node. After the node gets transaction data for affected segments, it creates the transaction with {{missingLookedUpEntries=true}} and the {{CommitCommand}} can be executed. > In this command's {{perform(...)}} the transaction is *first* marked as completed, then it enters the interceptor chain. There, the {{PrepareCommand}} is created in {{StateTransferInterceptor.visitCommitCommand}} but after this is processed the {{TxInterceptor}} finds out that the transaction is already completed and executes {{RollbackCommand}}, clearing locks etc. > Nevertheless, {{StateTransferInterceptor}} executes the initial {{CommitCommand}} afterwards. I suspect that this may be executed without the locks held. > Anyway, it is not correct to execute both commit and rollback on the same transaction. -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3593) Disallow storing a Lucene index when storeAsBinary is enabled

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3593?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3593: ------------------------------ Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2146 > Disallow storing a Lucene index when storeAsBinary is enabled > ------------------------------------------------------------- > > Key: ISPN-3593 > URL: https://issues.jboss.org/browse/ISPN-3593 > Project: Infinispan > Issue Type: Enhancement > Components: Lucene Directory > Affects Versions: 6.0.0.CR1 > Reporter: Sanne Grinovero > Assignee: Pedro Ruivo > Fix For: 6.0.0.Final > > > As discussed on the mailing list, this configuration doesn't make sense for the Lucene Directory and can cause trouble. > Let's add some validation to throw a runtime exception to disallow this configuration when a Directory is created on a cache. > Could probably be done in a very similar way as: > https://github.com/infinispan/infinispan/commit/2f6447e197abe2e9e62c796ab... -- 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

12 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3598) ISPN testsuite fails for RHEL 5, 6 && IBM JDK6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3598?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3598: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1016046 > ISPN testsuite fails for RHEL 5,6 && IBM JDK6 > --------------------------------------------- > > Key: ISPN-3598 > URL: https://issues.jboss.org/browse/ISPN-3598 > Project: Infinispan > Issue Type: Bug > Components: Core API > Affects Versions: 6.0.0.Beta1 > Environment: RHEL{5, 6} && IBM JDK6 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Attachments: ibm6_infinispan_failure_rhel5_x32.log, ibm6_infinispan_failure_rhel5_x64.log, ibm6_infinispan_failure_rhel6_x32.log, ibm6_infinispan_failure_rhel6_x64.log > > > The ISPN testsuite fails for the environment specified in the description. > You can find the core module's tracelog for all configurations attached. -- 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

12 years, 6 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 October 2013