April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4163) CacheAuthorizationTest.testAllCombinations always fails on JDK8

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4163?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4163: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > CacheAuthorizationTest.testAllCombinations always fails on JDK8 > --------------------------------------------------------------- > > Key: ISPN-4163 > URL: https://issues.jboss.org/browse/ISPN-4163 > Project: Infinispan > Issue Type: Bug > Components: Security, Test Suite - Core > Affects Versions: 7.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Tristan Tarrant > Labels: testsuite_stability > Fix For: 7.0.0.Alpha4 > > > JDK8 added some new default methods to ConcurrentMap, and SecureCacheTestDriver doesn't cover them. This actually raises the question of whether we could provide our own implementations while still keeping compatibility with JDK6... > {noformat} > java.lang.Exception: Class org.infinispan.security.SecureCacheTestDriver needs to declare a method with the following signature: void testReplaceAll_BiFunction(SecureCache<String, String> cache) {} > at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:158) > Caused by: java.lang.NoSuchMethodException: org.infinispan.security.SecureCacheTestDriver.testReplaceAll_BiFunction(org.infinispan.security.SecureCache) > at java.lang.Class.getMethod(Class.java:1773) > at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:109) ... 20 more > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4159) DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4159?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4159: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > DefaultTwoWayKey2StringMapper encodes objects to strings in a manner that is incompatible with string handling of some databases > -------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-4159 > URL: https://issues.jboss.org/browse/ISPN-4159 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > DefaultTwoWayKey2StringMapper uses two neat tricks. > 1. it does not encode all supported types, it only encodes non-Strings. Strings are kept unmodified. > 2. it uses a special prefix (unicode char 0xfeff) to mark which strings were encoded and which are plain. > Unfortunately some databases, notably MySql, interpret the endianness mark (0xfeff, 0xfffe), convert to native byte order and then drop it. > This leaves us with no clue the string is not an actual String but an encoded representation of another type. This misinterpretation leads later to ClassCastExceptions in various places in core and user code. > Proposed fix: get rid of #1 and #2 optimisations. Encode all objects, including Strings and always use the ?n prefix (where n stands for the original type). Drop the 0xFEFF marker prefix. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4166) useSynchronization should be disabled by default

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4166?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4166: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > useSynchronization should be disabled by default > ------------------------------------------------ > > Key: ISPN-4166 > URL: https://issues.jboss.org/browse/ISPN-4166 > Project: Infinispan > Issue Type: Feature Request > Components: Configuration, Transactions > Affects Versions: 6.0.2.Final > Reporter: Dan Berindei > Assignee: Ion Savin > Priority: Critical > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > When Infinispan registers with the transaction manager as a synchronization, failures during commit are not reported to the user. > Even if registering as a synchronization is faster in some cases, the default should be the safe version. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4133) DistSyncL1FuncTest.testNonOwnerRetrievesValueFromBackupOwnerWhileWrite

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4133?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4133: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > DistSyncL1FuncTest.testNonOwnerRetrievesValueFromBackupOwnerWhileWrite > ---------------------------------------------------------------------- > > Key: ISPN-4133 > URL: https://issues.jboss.org/browse/ISPN-4133 > Project: Infinispan > Issue Type: Task > Components: Core, Test Suite - Core > Reporter: Sanne Grinovero > Assignee: William Burns > Fix For: 7.0.0.Alpha4 > > > I'm disabling this test, this is the tracker issue to get it eventually fixed: > {noformat}testNonOwnerRetrievesValueFromBackupOwnerWhileWrite(org.infinispan.distribution.DistSyncL1FuncTest) Time elapsed: 0.01 sec <<< FAILURE! > java.lang.AssertionError: Entry for key [key-to-the-cache] should be in L1 on cache at [DistSyncL1FuncTest-NodeA-39542]! > at org.infinispan.distribution.DistributionTestHelper.assertIsInL1(DistributionTestHelper.java:31) > at org.infinispan.distribution.BaseDistFunctionalTest.assertIsInL1(BaseDistFunctionalTest.java:183) > at org.infinispan.distribution.DistSyncL1FuncTest.testNonOwnerRetrievesValueFromBackupOwnerWhileWrite(DistSyncL1FuncTest.java:280) > 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:606) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:714) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231) > 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.run(FutureTask.java:262) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:744) > Results : > Failed tests: > DistSyncL1FuncTest.testNonOwnerRetrievesValueFromBackupOwnerWhileWrite:280->BaseDistFunctionalTest.assertIsInL1:183 Entry for key [key-to-the-cache] should be in L1 on cache at [DistSyncL1FuncTest-NodeA-39542]! > {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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4149) Inject version details into org.infinispan.Version during build

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4149?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4149: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > Inject version details into org.infinispan.Version during build > --------------------------------------------------------------- > > Key: ISPN-4149 > URL: https://issues.jboss.org/browse/ISPN-4149 > Project: Infinispan > Issue Type: Task > Components: Build process > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Minor > Fix For: 7.0.0.Alpha4 > > -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4190) Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4190?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4190: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > Use Message.Flag.DONT_LOOPBACK instead of RequestOptions.setExclusionList > ------------------------------------------------------------------------- > > Key: ISPN-4190 > URL: https://issues.jboss.org/browse/ISPN-4190 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 7.0.0.Alpha2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4 > > > We are currently using {{RequestOptions.setExclusionList(channel.getAddress())}} in CommandAwareRpcDispatcher, to prevent the sender of an RPC to receive that message. We can't use {{Channel.setDiscardOwnMessages(true)}}, because TO requires messages to be delivered to self. > JGroups 3.5.0.Beta2 has added a {{DONT_LOOPBACK}} flag, which should be a lot more efficient than using the exclusion list. We should start using it. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4192) Adding a clustered in a local cache fails with NullPointerException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4192?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4192: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > Adding a clustered in a local cache fails with NullPointerException > ------------------------------------------------------------------- > > Key: ISPN-4192 > URL: https://issues.jboss.org/browse/ISPN-4192 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: William Burns > Fix For: 7.0.0.Alpha4 > > > members is null > {code} > Caused by: java.lang.NullPointerException > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addedListener(CacheNotifierImpl.java:594) > at org.infinispan.notifications.impl.AbstractListenerImpl.validateAndAddListenerInvocation(AbstractListenerImpl.java:154) > at org.infinispan.notifications.cachelistener.CacheNotifierImpl.addListener(CacheNotifierImpl.java:578) > at org.infinispan.cache.impl.CacheImpl.addListener(CacheImpl.java:560) > {code} -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4182) ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4182?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4182: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > ClusteredCacheWithAsyncDirTest does not properly ensure each db url is unique for parallel tests > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4182 > URL: https://issues.jboss.org/browse/ISPN-4182 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 7.0.0.Alpha1 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 630 > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > The test should ensure the db url is not the same across nodes of all parallel tests because they all run in the same jvm and the H2 instances might collide. -- 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, 12 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4180) Configuration parsing incorrectly logs that the cache name is ignored

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4180?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4180: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > Configuration parsing incorrectly logs that the cache name is ignored > --------------------------------------------------------------------- > > Key: ISPN-4180 > URL: https://issues.jboss.org/browse/ISPN-4180 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Reporter: Jakub Markos > Assignee: Galder Zamarreño > Priority: Minor > Fix For: 7.0.0.Alpha4 > > > Here: > https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... > If you configure a cache name, you get: > {code} > INFO [org.infinispan.configuration.parsing.Parser70] (ServerService Thread Pool -- 15) ISPN000293: Ignoring XML attribute NAME, please remove from configuration file > {code} -- 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, 12 months

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4176?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4176: -------------------------------- Fix Version/s: 7.0.0.Alpha4 (was: 7.0.0.Alpha3) > 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: Dan Berindei > Fix For: 7.0.0.Alpha4 > > > {{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 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, 12 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 April 2014