[JBoss JIRA] (ISPN-5123) MultiNodeDistributedTest dealock
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-5123:
---------------------------------------
Summary: MultiNodeDistributedTest dealock
Key: ISPN-5123
URL: https://issues.jboss.org/browse/ISPN-5123
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Query
Affects Versions: 7.1.0.Alpha1
Reporter: Gustavo Fernandes
I've been seeing this intermittent problem in my environment. Sometimes the query hangs for 30 min (and then proceeds). See attached stack trace.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes reassigned ISPN-5103:
---------------------------------------
Assignee: Gustavo Fernandes
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
> Assignee: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-3204) Implement Last-Modified header returned by REST endpoint correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3204?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3204:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1039911|https://bugzilla.redhat.com/show_bug.cgi?id=1039911] from NEW to CLOSED
> Implement Last-Modified header returned by REST endpoint correctly
> ------------------------------------------------------------------
>
> Key: ISPN-3204
> URL: https://issues.jboss.org/browse/ISPN-3204
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 5.3.0.CR1, 6.0.0.Final
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Labels: Server
>
> As described in ISPN-3153, the Last-Modified HTTP header does not always return correct date/time of the last modification.
> The goal of this JIRA is to fix this behaviour.
> Explanation of the bug:
> "Since immortal entries never die, we don't track creation time for them. We don't wanna be doing that either cos it takes valuable space that's might only be relevant for REST. In fact, we don't have anything that maps directly to last-modified per se. For transient entries, we track when the entry was last used (read or write) and for mortal entries, we track the creation time, which is not necessarily last modified time. Last-modified returns the expected value only when timeToLiveSeconds has been set and we're tracking creation time (mortal entry)."
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5112) SpringEmbeddedCacheManagerFactoryBeanTest and InfinispanEmbeddedCacheManagerFactoryBeanTest tests fail with FileNotFoundException exception
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-5112?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-5112:
------------------------------------
Git Pull Request: (was: https://github.com/infinispan/jdg/pull/421)
> SpringEmbeddedCacheManagerFactoryBeanTest and InfinispanEmbeddedCacheManagerFactoryBeanTest tests fail with FileNotFoundException exception
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5112
> URL: https://issues.jboss.org/browse/ISPN-5112
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 7.0.1.Final, 7.0.2.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: testsuite_stability
>
> {noformat}
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: configurationFile property specifies value jgroups-tcp.xml that could not be read!
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:254)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:570)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:536)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest$2.call(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:82)
> at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1277)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest.infinispanEmbeddedCacheManagerFactoryBeanShouldCreateACustomizedCacheManagerIfGivenADefaultConfigurationLocation(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:75)
> 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:745)
> Caused by: org.infinispan.commons.CacheConfigurationException: configurationFile property specifies value jgroups-tcp.xml that could not be read!
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:398)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:310)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:354)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
> 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.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:232)
> ... 26 more
> Caused by: java.io.FileNotFoundException: jgroups-tcp.xml
> ... 40 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5103) Inefficient index updates cause high cost merges and increase overall latency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5103?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5103:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1175382|https://bugzilla.redhat.com/show_bug.cgi?id=1175382] from NEW to ASSIGNED
> Inefficient index updates cause high cost merges and increase overall latency
> -----------------------------------------------------------------------------
>
> Key: ISPN-5103
> URL: https://issues.jboss.org/browse/ISPN-5103
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.2.Final, 7.1.0.Alpha1
> Reporter: Gustavo Fernandes
>
> Currently every change to the index is done Lucene-wise combining two operations:
> * Delete by query, using a boolean query on the id plus the entity class
> * Add
>
> Under high load, specially during merges those numerous deletes provoke very long delays causing high latency.
> We should instead use a simple Lucene Update to add/change documents, since internally it translates to a Delete by term plus an Add operation, and delete by terms are extremely efficient in Lucene.
> Some local tests showed average latency of updating the index using this strategy to drop 4 times, both for the SYNC and ASYNC backends
> With relation to sharing the index between entities, which was the original motivation of the Delete by query plus add strategy, we have two scenarios:
> * Same cache with multiple entity types: that's a non-issue, since obviously there's no id collision in this case
> * Different caches with the same index: this scenario happens when different caches shares the same index, for ex:
> {code}
> @Indexed(indexName=common)
> public class Country { ... }
> @Indexed(indexName=common)
> public class Currency { ... }
> cm.getCache("currencies").put(1, new Currency(...))
> cm.getCache("countries").put(1, new Country(...))
> {code}
> This would require a delete by query in order to persist both a Country and a Currency with id=1.
> It would also require setting "default.exclusive_index_use", "false", with the associated cost of having to reopen the IndexWriter on every operation.
> Given the performance gain of doing a simple Update is considerable, we should make the corner case supported by extra configuration or alternatively, generate a unique @ProvidedId, including the entity class or the cache name that work for all cases described above.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-3959) JdbcBinaryStore's expiration locks buckets indefinitely
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3959?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3959:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1176265|https://bugzilla.redhat.com/show_bug.cgi?id=1176265] from NEW to ASSIGNED
> JdbcBinaryStore's expiration locks buckets indefinitely
> -------------------------------------------------------
>
> Key: ISPN-3959
> URL: https://issues.jboss.org/browse/ISPN-3959
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.2.Final, 7.0.0.Alpha4
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Fix For: 7.0.0.Alpha5, 7.0.0.Final
>
>
> The buckets are locked in eviction thread (in the main purge method), while unlocked in BucketPurger.call() which is executed in persistence thread. The unlock fails and the buckets stay locked indefinitely.
> Another error is that the Bucket class is not serializable.
> This is also a bug in BaseStoreTest as this uses WithinThreadExecutor as the executor for purging while usually this is done in different thread. Moreover, as the purge method is actually not obliged to purge anything, the test does not test the purging itself, but rather a check for expired entry when it is loaded (contains operation). The purging should be enforced by purge listener (calling the purge method until all entries are purged).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (ISPN-5112) SpringEmbeddedCacheManagerFactoryBeanTest and InfinispanEmbeddedCacheManagerFactoryBeanTest tests fail with FileNotFoundException exception
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5112?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5112:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1178649|https://bugzilla.redhat.com/show_bug.cgi?id=1178649] from NEW to POST
> SpringEmbeddedCacheManagerFactoryBeanTest and InfinispanEmbeddedCacheManagerFactoryBeanTest tests fail with FileNotFoundException exception
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5112
> URL: https://issues.jboss.org/browse/ISPN-5112
> Project: Infinispan
> Issue Type: Bug
> Components: Spring Integration
> Affects Versions: 7.0.1.Final, 7.0.2.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Vitalii Chepeliuk
> Labels: testsuite_stability
>
> {noformat}
> org.infinispan.manager.EmbeddedCacheManagerStartupException: org.infinispan.commons.CacheConfigurationException: configurationFile property specifies value jgroups-tcp.xml that could not be read!
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:254)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:570)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:536)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:414)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest$2.call(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:82)
> at org.infinispan.test.TestingUtil.withCacheManager(TestingUtil.java:1277)
> at org.infinispan.spring.support.embedded.InfinispanEmbeddedCacheManagerFactoryBeanTest.infinispanEmbeddedCacheManagerFactoryBeanShouldCreateACustomizedCacheManagerIfGivenADefaultConfigurationLocation(InfinispanEmbeddedCacheManagerFactoryBeanTest.java:75)
> 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:745)
> Caused by: org.infinispan.commons.CacheConfigurationException: configurationFile property specifies value jgroups-tcp.xml that could not be read!
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.buildChannel(JGroupsTransport.java:398)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannel(JGroupsTransport.java:310)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.initChannelAndRPCDispatcher(JGroupsTransport.java:354)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190)
> 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.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:627)
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:530)
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:232)
> ... 26 more
> Caused by: java.io.FileNotFoundException: jgroups-tcp.xml
> ... 40 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months