July 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4551) RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset

by Ion Savin (JIRA)

Ion Savin created ISPN-4551: ------------------------------- Summary: RestStore parallel iteration fails for non-string keys if UTF-8 is not the default charset Key: ISPN-4551 URL: https://issues.jboss.org/browse/ISPN-4551 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Alpha5 Reporter: Ion Savin Assignee: Ion Savin On systems where UTF-8 is not the default charset parallel iteration over non-string keys fails. Non-string keys are mapped to strings prefixed by \uFEFF when the entry is stored. The key is URL-encoded and the prefix is stored properly. The GET /{cacheName} (all keys) response however uses the system-default charset and if that's not UTF-8 the prefix cannot be mapped and ends up being "?". To reproduce set the charset to ISO-8859-1 and run RestStoreParallelIterationTest and you should see failures similar to this one: {noformat} [testng-RestStoreParallelIterationTest] Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed. 10:11:27,629 ERROR [org.infinispan.test.fwk.UnitTestTestNGListener] (testng-RestStoreParallelIterationTest) Test testSequentialIteration(org.infinispan.persistence.rest.RestStoreParallelIterationTest) failed. org.infinispan.persistence.spi.PersistenceException: ISPN022005: Error loading entries from remote server at org.infinispan.persistence.rest.RestStore.process(RestStore.java:295) at org.infinispan.persistence.ParallelIterationTest.runIterationTest(ParallelIterationTest.java:103) at org.infinispan.persistence.ParallelIterationTest.testSequentialIteration(ParallelIterationTest.java:64) 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:84) 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:348) at org.testng.SuiteRunner.access$000(SuiteRunner.java:38) at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382) 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) Caused by: org.infinispan.persistence.spi.PersistenceException: Execution exception! at org.infinispan.persistence.rest.RestStore.process(RestStore.java:292) ... 22 more Caused by: java.util.concurrent.ExecutionException: java.lang.NullPointerException at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:188) at org.infinispan.executors.ExecutorAllCompletionService.pollUntilEmpty(ExecutorAllCompletionService.java:48) at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:32) at org.infinispan.persistence.rest.RestStore.submitProcessTask(RestStore.java:304) at org.infinispan.persistence.rest.RestStore.process(RestStore.java:284) ... 22 more Caused by: java.lang.NullPointerException at org.infinispan.persistence.ParallelIterationTest$2.processEntry(ParallelIterationTest.java:106) at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:314) at org.infinispan.persistence.rest.RestStore$1.call(RestStore.java:304) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at org.infinispan.util.concurrent.WithinThreadExecutor.execute(WithinThreadExecutor.java:22) at java.util.concurrent.ExecutorCompletionService.submit(ExecutorCompletionService.java:181) at org.infinispan.executors.ExecutorAllCompletionService.submit(ExecutorAllCompletionService.java:31) ... 24 more {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4547) Replication queue should replicate the first command immediately

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4547?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4547: ------------------------------------ It would make sense to limit the size of the queue, both to have a maximum batch size and to block user threads from sending too many commands. So we might still need 2 different settings. > Replication queue should replicate the first command immediately > ---------------------------------------------------------------- > > Key: ISPN-4547 > URL: https://issues.jboss.org/browse/ISPN-4547 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: William Burns > Priority: Minor > Fix For: 7.0.0.Final > > > The replication queue only replicates commands when the replication queue is full or the replication thread wakes up periodically. > If a new command is added to an empty replication queue, the replication thread should wake up immediately and broadcast it, otherwise it will add a significant latency to the replication under light load. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4550) JpaStoreOOMETest.testProcessClear always fails

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-4550?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-4550: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2735 > JpaStoreOOMETest.testProcessClear always fails > ---------------------------------------------- > > Key: ISPN-4550 > URL: https://issues.jboss.org/browse/ISPN-4550 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > Test history: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=-29... > I think the test might be working with an in-memory H2 database, which would explain the failure. We could try to run the stress tests with another DB (perhaps with the mysql profile). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4306) HR client auth over kerberos has wrong AccessControlContext

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4306?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4306: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta1 Resolution: Done > HR client auth over kerberos has wrong AccessControlContext > ----------------------------------------------------------- > > Key: ISPN-4306 > URL: https://issues.jboss.org/browse/ISPN-4306 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Reporter: Vojtech Juranek > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta1 > > > When HotRod client authneticate to HR server via kerberos, HR server obtains wrong {{AccessControlContext}}, which doesn't contain appropriate subject (to be more clear it's in [AuthorizationManagerImpl.checkPermission()|https://github.com/infinispan/...]). Returned subject is {{null}} and moreover this default {{AccessControlContext}} allows to do anything, so effectively the HR client can do anything, no matter what the permissions are. > Need to mention that in this case java {{SecurityManager}} is turned off, but as the same setup works with e.g. MD5 auth, we should keep some consistency and it shouldn't work in any case (and {{SecurityManager}} to be turned on should be a hard requirement to ISPN auth works) or it should work also in case of krb auth. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4550) JpaStoreOOMETest.testProcessClear always fails

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4550?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4550: ------------------------------- Summary: JpaStoreOOMETest.testProcessClear always fails (was: JP) Fix Version/s: 7.0.0.Beta1 Description: Test history: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=-29... I think the test might be working with an in-memory H2 database, which would explain the failure. We could try to run the stress tests with another DB (perhaps with the mysql profile). Priority: Blocker (was: Major) Labels: testsuite_stability (was: ) Assignee: Pedro Ruivo (was: Mircea Markus) Affects Version/s: 7.0.0.Alpha5 Component/s: Test Suite - Core > JpaStoreOOMETest.testProcessClear always fails > ---------------------------------------------- > > Key: ISPN-4550 > URL: https://issues.jboss.org/browse/ISPN-4550 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > Test history: http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=-29... > I think the test might be working with an in-memory H2 database, which would explain the failure. We could try to run the stress tests with another DB (perhaps with the mysql profile). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4550) JP

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4550: ---------------------------------- Summary: JP Key: ISPN-4550 URL: https://issues.jboss.org/browse/ISPN-4550 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Dan Berindei Assignee: Mircea Markus -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4549) StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4549?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4549: ------------------------------- Description: The test checks that the rebalance is complete by waiting for the {{CommittedViewAsString}} reported by the RpcManager MBean to be {{"DefaultConsistentHash\{numSegments=60, numOwners=2, members=\[node0/" + getCacheManagerName() + ", node1/" + getCacheManagerName() + "\]\}"}} and the {{PendingViewAsString}} to be {{null}}. But immediately after the 3rd server is stopped, the coordinator installs a topology with exactly the same string representation. It only starts the rebalance after that. So the test could start checking the number of entries before the rebalance actually started. Failure in CI: http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDiv&bu... was: The test checks that the rebalance is complete by waiting for the {{CommittedViewAsString}} reported by the RpcManager MBean to be {{"DefaultConsistentHash{numSegments=60, numOwners=2, members=[node0/" + getCacheManagerName() + ", node1/" + getCacheManagerName() + "]}"}} and the {{PendingViewAsString}} to be {{null}}. But immediately after the 3rd server is stopped, the coordinator installs a topology with exactly the same string representation. It only starts the rebalance after that. So the test could start checking the number of entries before the rebalance actually started. Failure in CI: http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDiv&bu... > StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures > ---------------------------------------------------------------------------------- > > Key: ISPN-4549 > URL: https://issues.jboss.org/browse/ISPN-4549 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > The test checks that the rebalance is complete by waiting for the {{CommittedViewAsString}} reported by the RpcManager MBean to be {{"DefaultConsistentHash\{numSegments=60, numOwners=2, members=\[node0/" + getCacheManagerName() + ", node1/" + getCacheManagerName() + "\]\}"}} and the {{PendingViewAsString}} to be {{null}}. > But immediately after the 3rd server is stopped, the coordinator installs a topology with exactly the same string representation. It only starts the rebalance after that. > So the test could start checking the number of entries before the rebalance actually started. > Failure in CI: http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDiv&bu... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4549) StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4549: ---------------------------------- Summary: StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures Key: ISPN-4549 URL: https://issues.jboss.org/browse/ISPN-4549 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Test Suite - Server Affects Versions: 7.0.0.Alpha5 Reporter: Dan Berindei Assignee: Mircea Markus Priority: Blocker Fix For: 7.0.0.Beta1 The test checks that the rebalance is complete by waiting for the {{CommittedViewAsString}} reported by the RpcManager MBean to be {{"DefaultConsistentHash{numSegments=60, numOwners=2, members=[node0/" + getCacheManagerName() + ", node1/" + getCacheManagerName() + "]}"}} and the {{PendingViewAsString}} to be {{null}}. But immediately after the 3rd server is stopped, the coordinator installs a topology with exactly the same string representation. It only starts the rebalance after that. So the test could start checking the number of entries before the rebalance actually started. Failure in CI: http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDiv&bu... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4549) StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4549?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4549: ------------------------------- Assignee: Galder Zamarreño (was: Mircea Markus) > StateTransferSuppressForMemcacheIT.testRebalanceWithJoinedNodeStop random failures > ---------------------------------------------------------------------------------- > > Key: ISPN-4549 > URL: https://issues.jboss.org/browse/ISPN-4549 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite - Server > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Priority: Blocker > Labels: testsuite_stability > Fix For: 7.0.0.Beta1 > > > The test checks that the rebalance is complete by waiting for the {{CommittedViewAsString}} reported by the RpcManager MBean to be {{"DefaultConsistentHash{numSegments=60, numOwners=2, members=[node0/" + getCacheManagerName() + ", node1/" + getCacheManagerName() + "]}"}} and the {{PendingViewAsString}} to be {{null}}. > But immediately after the 3rd server is stopped, the coordinator installs a topology with exactly the same string representation. It only starts the rebalance after that. > So the test could start checking the number of entries before the rebalance actually started. > Failure in CI: http://ci.infinispan.org/viewLog.html?buildId=9804&tab=buildResultsDiv&bu... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3937) Investigate the memory usage of JDBC cache stores when processing a large result set

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3937?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-3937: ---------------------------------- Assignee: Pedro Ruivo (was: Dan Berindei) > Investigate the memory usage of JDBC cache stores when processing a large result set > ------------------------------------------------------------------------------------ > > Key: ISPN-3937 > URL: https://issues.jboss.org/browse/ISPN-3937 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core, Loaders and Stores > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Pedro Ruivo > Priority: Critical > Fix For: 7.0.0.Final > > > Iterating over a huge ResultSet with MySQL seems to keep all the rows in memory: https://community.jboss.org/message/854402 > We should investigate whether we can limit the memory usage to a fixed amount and whether this affects other drivers as well. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues July 2014