[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years
[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
12 years