November 2012 - infinispan-issues

[JBoss JIRA] (ISPN-2008) Optimistic concurrency in REST server is not using atomic operations

by Eugen Dück (JIRA)

Eugen Dück created ISPN-2008: -------------------------------- Summary: Optimistic concurrency in REST server is not using atomic operations Key: ISPN-2008 URL: https://issues.jboss.org/browse/ISPN-2008 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.4.CR1 Reporter: Eugen Dück Assignee: Manik Surtani The REST server's optimistic currency control is not atomic. The sequence in e.g. a PUT request goes like this: * request.evaluatePreconditions * cache.put (if preconditions met) Which is not inside any lock (that would make it pessimistic, anyway), in other words, a race condition. This applies to the optimistic variants of PUT, POST, and DELETE. -- 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

11 years, 10 months

4
9
0 / 0

[JBoss JIRA] (ISPN-2300) Versioned Transactional Cache issues

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-2300: --------------------------------- Summary: Versioned Transactional Cache issues Key: ISPN-2300 URL: https://issues.jboss.org/browse/ISPN-2300 Project: Infinispan Issue Type: Bug Components: Transactions Affects Versions: 5.2.0.Alpha3 Reporter: Pedro Ruivo Assignee: Mircea Markus Description from http://lists.jboss.org/pipermail/infinispan-dev/2012-September/011205.html 1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods the test cases) In this tests, it was updating the cache entry with a null version. This originates later a IllegalStateException when it tries to perform the write skew check and the version is null. I have fixed this problem in this way: if the command fails (PutCommand, RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the MvccEntry to avoid to update the entry in the DataContainer. 2) testClear in distributed mode I have no clear idea how to solve this problem but it looks like the PrepareCommand (with the ClearCommand) is not sent to all the nodes in the cluster. Then, when I do a get, a remote get is performed and the key is still there. I think that it is not the desired behavior. 3) testRemoveUnexistingEntry In this test, it tries to remove a key that does not exists but it does not success due to a NullPointerException. I have looked deeper and I check that the transaction's lookup entries map has an entry with [key => null] and when it tries to perform the write skew check in that key, a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper) [1] https://github.com/pruivo/infinispan/tree/t_replace_fix [2] https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav... -- 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

11 years, 10 months

4
8
0 / 0

[JBoss JIRA] (ISPN-2550) NoSuchElementException in Hot Rod Encoder

by Michal Linhard (JIRA)

Michal Linhard created ISPN-2550: ------------------------------------ Summary: NoSuchElementException in Hot Rod Encoder Key: ISPN-2550 URL: https://issues.jboss.org/browse/ISPN-2550 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.2.0.Beta4 Reporter: Michal Linhard Assignee: Galder Zamarreño Tomas noticed this a while ago in a specific functional test: https://bugzilla.redhat.com/show_bug.cgi?id=875151 I'm creating a more general JIRA, cause I'm having this in resilience test. What I found by quick debug, is that here: https://github.com/infinispan/infinispan/blob/master/server/hotrod/src/ma... {code} for (segmentIdx <- 0 until numSegments) { val denormalizedSegmentHashIds = allDenormalizedHashIds(segmentIdx) val segmentOwners = ch.locateOwnersForSegment(segmentIdx) for (ownerIdx <- 0 until segmentOwners.length) { val address = segmentOwners(ownerIdx % segmentOwners.size) val serverAddress = members(address) val hashId = denormalizedSegmentHashIds(ownerIdx) log.tracef("Writing hash id %d for %s:%s", hashId, serverAddress.host, serverAddress.port) writeString(serverAddress.host, buf) writeUnsignedShort(serverAddress.port, buf) buf.writeInt(hashId) } } {code} we're trying to obtain serverAddress for nonexistent address and NoSuchElementException is not handled properly. It hapens after I kill a node in a resilience test and the exception appears when querying for the node in the members cache. -- 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

11 years, 10 months

5
13
0 / 0

[JBoss JIRA] (ISPN-2576) API documentation navigation bar is broken

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2576: ---------------------------------- Summary: API documentation navigation bar is broken Key: ISPN-2576 URL: https://issues.jboss.org/browse/ISPN-2576 Project: Infinispan Issue Type: Bug Components: Build process Affects Versions: 5.2.0.Beta5 Reporter: Dan Berindei Assignee: Mircea Markus Fix For: 5.2.0.Beta6 This is probably related to the plugin updates we made recently: the javadocs navigation bar now appears as a plain list of links. -- 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

11 years, 10 months

4
7
0 / 0

[JBoss JIRA] (ISPN-2508) The async executor is executed synchronously

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2508: ----------------------------------- Summary: The async executor is executed synchronously Key: ISPN-2508 URL: https://issues.jboss.org/browse/ISPN-2508 Project: Infinispan Issue Type: Bug Reporter: Anna Manukyan Assignee: Mircea Markus The functional tests which are testing the custom asynchronous executor, are failing with JDG-6.1.0.ER1 build due to the following reason: the tests are verifying that the executor was executed in separate thread, i.e. asynchronously, but starting from the new Infinispan version, the executor's execution thread is the same as the one where the test is executed. You can find the failing test results here: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-jdbc-cache-sto... and here: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-jdbc-cache-sto... The test is located here: https://svn.devel.redhat.com/repos/jboss-qa/jdg/jdg-functional-tests/trun... Best regards, Anna. -- 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

11 years, 10 months

4
15
0 / 0

[JBoss JIRA] (ISPN-2176) Test LocalKeyAffinityServiceTest.testFilteredSingleKey fail randomly

by Martin Gencur (JIRA)

Martin Gencur created ISPN-2176: ----------------------------------- Summary: Test LocalKeyAffinityServiceTest.testFilteredSingleKey fail randomly Key: ISPN-2176 URL: https://issues.jboss.org/browse/ISPN-2176 Project: Infinispan Issue Type: Task Affects Versions: 5.1.6.FINAL (JDG) Reporter: Martin Gencur Assignee: Tristan Tarrant Priority: Minor Example failure can be found at https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... In the next run everything was fine: https://hudson.qa.jboss.com/hudson/view/EDG6/view/EDG-REPORTS-FUNC/job/ed... -- 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

11 years, 10 months

5
14
0 / 0

[JBoss JIRA] (ISPN-2380) OfflineStatusTest.timeBasedTakeOffline failure

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-2380: ----------------------------------- Summary: OfflineStatusTest.timeBasedTakeOffline failure Key: ISPN-2380 URL: https://issues.jboss.org/browse/ISPN-2380 Project: Infinispan Issue Type: Bug Components: Cross-Site Replication Affects Versions: 5.2.0.Beta1 Reporter: Adrian Nistor Assignee: Mircea Markus Fix For: 5.2.0.CR1 This test fails constantly on my machine. 2012-10-11 10:36:35,388 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-OfflineStatusTest) Test timeBasedTakeOffline(org.infinispan.xsite.offline.OfflineStatusTest) failed. java.lang.AssertionError: expected:<true> but was:<false> at org.testng.Assert.fail(Assert.java:89) at org.testng.Assert.failNotEquals(Assert.java:480) at org.testng.Assert.assertTrue(Assert.java:37) at org.testng.Assert.assertTrue(Assert.java:47) at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:76) at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:59) at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:132) at org.infinispan.xsite.offline.OfflineStatusTest.timeBasedTakeOffline(OfflineStatusTest.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) -- 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

11 years, 10 months

3
8
0 / 0

[JBoss JIRA] (ISPN-2548) JDBCCacheStore doesn't work propertly with MSSql

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-2548: ----------------------------------- Summary: JDBCCacheStore doesn't work propertly with MSSql Key: ISPN-2548 URL: https://issues.jboss.org/browse/ISPN-2548 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.2.0.Beta4 Reporter: Anna Manukyan Assignee: Mircea Markus The functional tests for JDBCCacheStore using MSSQL2008 R2 as a store, are failing. In case if the configuration is set with properties: .addProperty("dropTableOnExit", "false") .addProperty("createTableOnStart", "true") The following exception arrise: {code} org.infinispan.loaders.CacheLoaderException: com.microsoft.sqlserver.jdbc.SQLServerException: There is already an object named 'edg_bin____defaultcache' in the database. at org.infinispan.loaders.jdbc.TableManipulation.executeUpdateSql(TableManipulation.java:187) at org.infinispan.loaders.jdbc.TableManipulation.createTable(TableManipulation.java:160) at org.infinispan.loaders.jdbc.TableManipulation.start(TableManipulation.java:262) at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.doConnectionFactoryInitialization(JdbcBinaryCacheStore.java:514) at org.infinispan.loaders.jdbc.binary.JdbcBinaryCacheStore.start(JdbcBinaryCacheStore.java:102) at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:159) ... 104 more {code} Please note, that MSSql database is clean before the test run, this means that the table is not there. But the exception is in place anyway. -- 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

11 years, 10 months

4
17
0 / 0

[JBoss JIRA] (ISPN-2566) TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly

by Dan Berindei (JIRA)

Dan Berindei created ISPN-2566: ---------------------------------- Summary: TopologyAwareConsistentHashFactory rebalance doesn't redistribute data properly Key: ISPN-2566 URL: https://issues.jboss.org/browse/ISPN-2566 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 5.2.0.Beta4 Reporter: Dan Berindei Assignee: Dan Berindei Priority: Critical Fix For: 5.2.0.Final Say we have a topology-aware cache with numOwners = 2 and two nodes: A(machine=m1) and B(machine=m1). When node C(machine=m2) joins, it should own every key, either as a primary or as a backup owner. This doesn't happen, node C owns just as many segments as nodes A and B. Example: {noformat} 19:21:17,295 TRACE [org.infinispan.topology.ClusterTopologyManagerImpl] (undefined) Updating cache topology topology for rebalance: CacheTopology{id=3, currentCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[node0/default(primary), node1/default(primary)], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 0 1, 28: 0 1, 29: 0 1, 30: 0 1, 31: 0 1, 32: 0 1, 33: 0 1, 34: 0 1, 35: 0 1, 36: 0 1, 37: 0 1, 38: 0 1, 39: 0 1, 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0, 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0, 64: 1 0, 65: 1 0, 66: 1 0, 67: 1 0, 68: 1 0, 69: 1 0, 70: 1 0, 71: 1 0, 72: 1 0, 73: 1 0, 74: 1 0, 75: 1 0, 76: 1 0, 77: 1 0, 78: 1 0, 79: 1 0}, pendingCH=DefaultConsistentHash{numSegments=80, numOwners=2, members=[node0/default(primary), node1/default(primary), node2/default(secondary)], owners={0: 0 1, 1: 0 1, 2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0 1, 11: 0 1, 12: 0 1, 13: 0 1, 14: 0 1, 15: 0 1, 16: 0 1, 17: 0 1, 18: 0 1, 19: 0 1, 20: 0 1, 21: 0 1, 22: 0 1, 23: 0 1, 24: 0 1, 25: 0 1, 26: 0 1, 27: 2 0, 28: 2 0, 29: 2 0, 30: 2 0, 31: 2 0, 32: 2 0, 33: 2 0, 34: 2 0, 35: 2 0, 36: 2 0, 37: 2 0, 38: 2 0, 39: 2 0, 40: 1 0, 41: 1 0, 42: 1 0, 43: 1 0, 44: 1 0, 45: 1 0, 46: 1 0, 47: 1 0, 48: 1 0, 49: 1 0, 50: 1 0, 51: 1 0, 52: 1 0, 53: 1 0, 54: 1 0, 55: 1 0, 56: 1 0, 57: 1 0, 58: 1 0, 59: 1 0, 60: 1 0, 61: 1 0, 62: 1 0, 63: 1 0, 64: 1 0, 65: 1 0, 66: 1 0, 67: 2 1, 68: 2 1, 69: 2 1, 70: 2 1, 71: 2 1, 72: 2 1, 73: 2 1, 74: 2 1, 75: 2 1, 76: 2 1, 77: 2 1, 78: 2 1, 79: 2 1}} {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

11 years, 10 months

4
6
0 / 0

[JBoss JIRA] (ISPN-2318) Reimplement a Topology-Aware Consistent Hash

by Erik Salter (JIRA)

Erik Salter created ISPN-2318: --------------------------------- Summary: Reimplement a Topology-Aware Consistent Hash Key: ISPN-2318 URL: https://issues.jboss.org/browse/ISPN-2318 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 5.2.0.Alpha3 Reporter: Erik Salter Assignee: Mircea Markus Even with the advent of x-site replication, the TACH is useful to stripe key ownership across machines and/or racks for resiliency. This feature should be refactored from the 5.1 impl. -- 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

11 years, 10 months

5
19
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2012