October 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2069) Implement a caching servlet filter

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2069: ------------------------------------- Summary: Implement a caching servlet filter Key: ISPN-2069 URL: https://issues.jboss.org/browse/ISPN-2069 Project: Infinispan Issue Type: Feature Request Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Implement a servlet filter for caching web requests keyed on servlet path, parameters and headers. Look into support for web caching standards such as ESI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
2
0 / 0

[JBoss JIRA] (ISPN-2311) JDBC store configuration builder is not entirely fluent

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2311: ------------------------------------- Summary: JDBC store configuration builder is not entirely fluent Key: ISPN-2311 URL: https://issues.jboss.org/browse/ISPN-2311 Project: Infinispan Issue Type: Bug Components: Configuration Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 5.2.0.Final Some items in the JDBC configuration builder API (e.g. TableManipulationConfiguration) are not completely fluent (e.g. they interrupt the JDBC CacheStore builder fluency) -- 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, 3 months

2
3
0 / 0

[JBoss JIRA] (ISPN-2361) AbstractTxLockingInterceptor.lockKeyAndCheckOwnership() anomalies: can wait indefinitelly or it can wait too little due to spurious wakeups

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2361: ----------------------------------- Summary: AbstractTxLockingInterceptor.lockKeyAndCheckOwnership() anomalies: can wait indefinitelly or it can wait too little due to spurious wakeups Key: ISPN-2361 URL: https://issues.jboss.org/browse/ISPN-2361 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.2.0.Alpha4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.2.0.Beta1 When waiting for pending locks we can get into 2 cases that are not correctly handled: 1. The check for remaining time (remaining < 0) is incorrect because if remaining == 0 it will try to wait for transactions (waitForLockRelease) with 0 timeout (indefinitely). 2. CacheTransaction.waitForLockRelease() can return earlier than the specified timeout and the transaction might not yet be complete. This happens because the mechanism inside waitForLockRelease() does not protect itself from spurious wakeups leaving this to the caller. AbstractTxLockingInterceptor must be fixed to take care of this. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] (ISPN-2337) Query iterators are buggy

by Marko Lukša (JIRA)

Marko Lukša created ISPN-2337: --------------------------------- Summary: Query iterators are buggy Key: ISPN-2337 URL: https://issues.jboss.org/browse/ISPN-2337 Project: Infinispan Issue Type: Bug Components: Querying Affects Versions: 5.2.0.Alpha4 Reporter: Marko Lukša Assignee: Marko Lukša I have found multiple problems with the iterators returned by CacheQueryImpl. - using LazyIterator with fetchSize fails with ArrayIndexOutOfBoundsException - calling previous() after next() doesn't return expected element - calling nextIndex() on a new iterator should return 0, not 1 (the same also applies when calling nextIndex() after calling first()) - if fetchSize is greater than 1, LazyIterator fills the whole buffer on every invocation of .previous() - nextIndex() and previousIndex() throw NoSuchElementException, which violates the contract of ListInterface - next() and previous() throw ArrayIndexOutOfBoundsException when they should be throwing NoSuchElementException - ... -- 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, 3 months

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-939) Index corruption when remote node dies during commit

by Tristan Tarrant (JIRA)

Index corruption when remote node dies during commit ---------------------------------------------------- Key: ISPN-939 URL: https://issues.jboss.org/browse/ISPN-939 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.1.CR2 Reporter: Tristan Tarrant Assignee: Sanne Grinovero Using a scenario similar to the one described in ISPN-909: Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction, hash numOwners=2) Node 1: coordinator, IndexWriter open constantly and writing a stream of documents, committing after each one Node 2: opens a read-only IndexReader to perform queries, using reopen to keep in sync with the updates coming from node 1 If we "kill -9" node 2 (to simulate a crash), we get a SuspectException in node 1 during the pre-commit phase (within IndexWriter.commit()). Catching the Throwable we then close() the writer but from then on we get "Read past EOF" errors when trying to access the index (both with readers and writers). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

3
20
0 / 0

[JBoss JIRA] (ISPN-2142) APPLY_STATE in StateTransferControlCommand uses an InvocationContext having local=true

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-2142: ------------------------------------- Summary: APPLY_STATE in StateTransferControlCommand uses an InvocationContext having local=true Key: ISPN-2142 URL: https://issues.jboss.org/browse/ISPN-2142 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Critical Fix For: 5.2.0.ALPHA2 This causes nasty side effects on Query as it listens to write operations and needs to strictly discard those not originating locally -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2358) TestingUtil.waitForRehashToComplete returns too soon and causes random test failures

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2358: ----------------------------------- Summary: TestingUtil.waitForRehashToComplete returns too soon and causes random test failures Key: ISPN-2358 URL: https://issues.jboss.org/browse/ISPN-2358 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.2.0.Alpha4 Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 5.2.0.Beta1 TestingUtil.waitForRehashToComplete returns as soon as the LocalTopologyManager receives and dispatches the new CacheTopology. This is usually too early because the StateTransferManager and DistributionManager are in the process of being updated. We need to wait until StateTransferManager has finished processing of the new topology. Currently MultipleNodesLeavingTest is failing randomly because of this. -- 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, 3 months

2
1
0 / 0

[JBoss JIRA] (ISPN-2356) xsite replication: only the first site replication eror is reported

by Bela Ban (JIRA)

Bela Ban created ISPN-2356: ------------------------------ Summary: xsite replication: only the first site replication eror is reported Key: ISPN-2356 URL: https://issues.jboss.org/browse/ISPN-2356 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication Affects Versions: 5.2.0.Alpha4 Reporter: Bela Ban Assignee: Mircea Markus Priority: Minor When we have a couple of backup sites (e.g. NYC and SFO) and none of them are running, a sync replication with backupFailurePolicy=FAIL with throw an exception on the first failure, e.g. SFO. However it will not report the failure for NYC. Not sure if this is crucial, but I suspect somewhere someone counts the failures per site, and in this case NYC would not show any failures until SFO is taken offline. The code is in BackupSenderImpl: {code} public void processResponses(BackupResponse backupResponse, VisitableCommand command, Transaction transaction) throws Throwable { backupResponse.waitForBackupToFinish(); SitesConfiguration sitesConfiguration = config.sites(); Map<String, Throwable> failures = backupResponse.getFailedBackups(); for (Map.Entry<String, Throwable> failure : failures.entrySet()) { BackupFailurePolicy policy = sitesConfiguration.getFailurePolicy(failure.getKey()); if (policy == BackupFailurePolicy.CUSTOM) { CustomFailurePolicy customFailurePolicy = siteFailurePolicy.get(failure.getKey()); command.acceptVisitor(null, new CustomBackupPolicyInvoker(failure.getKey(), customFailurePolicy, transaction)); } if (policy == BackupFailurePolicy.WARN) { log.warnXsiteBackupFailed(cacheName, failure.getKey(), failure.getValue()); } else if (policy == BackupFailurePolicy.FAIL) { throw new BackupFailureException(failure.getValue(),failure.getKey(), cacheName); } } } {code} Iterating through the failure map, we throw a BackupFailureException on the *first* failure. I suggest to either collect all exceptions (also when invoking the custom failure policy !) and throw them as a new exception (listing all of them) or to simply log the situation as an error. -- 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, 3 months

2
5
0 / 0

[JBoss JIRA] (ISPN-2354) AsyncStoreFunctionalTest fails intermittently

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2354?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2354: ----------------------------------- Labels: testsuite_stability (was: ) I'll have a look into this once we've integrated Karsten's async store. > AsyncStoreFunctionalTest fails intermittently > --------------------------------------------- > > Key: ISPN-2354 > URL: https://issues.jboss.org/browse/ISPN-2354 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 5.2.0.CR1 > > > AsyncStoreFunctionalTest sometimes fails with this assertion error: > {noformat} > 14:49:46,380 ERROR (testng-AsyncStoreFunctionalTest:) [UnitTestTestNGListener] Test testGetAfterRemove(org.infinispan.loaders.decorators.AsyncStoreFunctionalTest) failed. > java.lang.AssertionError: Keys not empty: [1] > at org.testng.AssertJUnit.fail(AssertJUnit.java:57) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22) > at org.infinispan.loaders.decorators.AsyncStoreFunctionalTest$3.call(AsyncStoreFunctionalTest.java:211) > at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1252) > at org.infinispan.loaders.decorators.AsyncStoreFunctionalTest.testGetAfterRemove(AsyncStoreFunctionalTest.java:165) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {noformat} -- 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, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2354) AsyncStoreFunctionalTest fails intermittently

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-2354?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-2354: ----------------------------------- Fix Version/s: 5.2.0.CR1 (was: 5.2.0.Final) > AsyncStoreFunctionalTest fails intermittently > --------------------------------------------- > > Key: ISPN-2354 > URL: https://issues.jboss.org/browse/ISPN-2354 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 5.2.0.CR1 > > > AsyncStoreFunctionalTest sometimes fails with this assertion error: > {noformat} > 14:49:46,380 ERROR (testng-AsyncStoreFunctionalTest:) [UnitTestTestNGListener] Test testGetAfterRemove(org.infinispan.loaders.decorators.AsyncStoreFunctionalTest) failed. > java.lang.AssertionError: Keys not empty: [1] > at org.testng.AssertJUnit.fail(AssertJUnit.java:57) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:22) > at org.infinispan.loaders.decorators.AsyncStoreFunctionalTest$3.call(AsyncStoreFunctionalTest.java:211) > at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1252) > at org.infinispan.loaders.decorators.AsyncStoreFunctionalTest.testGetAfterRemove(AsyncStoreFunctionalTest.java:165) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:74) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:673) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:846) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1170) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109) > at org.testng.TestRunner.runWorkers(TestRunner.java:1147) > at org.testng.TestRunner.privateRun(TestRunner.java:749) > at org.testng.TestRunner.run(TestRunner.java:600) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:317) > at org.testng.SuiteRunner.access$000(SuiteRunner.java:34) > at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:351) > at org.testng.internal.thread.ThreadUtil$CountDownLatchedRunnable.run(ThreadUtil.java:147) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > {noformat} -- 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, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2012