October 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3649) org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows machine with JDK6

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3649?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3649: ----------------------------------------------- Anna Manukyan <amanukya(a)redhat.com> made a comment on [bug 1021382|https://bugzilla.redhat.com/show_bug.cgi?id=1021382] See the issue description here: https://issues.jboss.org/browse/ISPN-3649 > org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows machine with JDK6 > ---------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-3649 > URL: https://issues.jboss.org/browse/ISPN-3649 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 6.0.0.CR1 > Environment: Windows 2008R2 && JDK6 > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > > org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows 2008R2 maching wiht JDK6. > The failure error is: > {code} > java.lang.AssertionError > at org.infinispan.persistence.remote.RemoteStoreRawValuesTest.assertEventuallyExpires(RemoteStoreRawValuesTest.java:91) > at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithLifespanAndIdle(BaseStoreTest.java:211) > 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:80) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) > 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$Sync.innerRun(FutureTask.java:303) > at java.util.concurrent.FutureTask.run(FutureTask.java:138) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > {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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3649) org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows machine with JDK6

by Anna Manukyan (JIRA)

Anna Manukyan created ISPN-3649: ----------------------------------- Summary: org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows machine with JDK6 Key: ISPN-3649 URL: https://issues.jboss.org/browse/ISPN-3649 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 6.0.0.CR1 Environment: Windows 2008R2 && JDK6 Reporter: Anna Manukyan Assignee: Mircea Markus org.infinispan.persistence.remote.RemoteStoreRawValuesTest.testLoadAndStoreWithLifespanAndIdle fails periodically on Windows 2008R2 maching wiht JDK6. The failure error is: {code} java.lang.AssertionError at org.infinispan.persistence.remote.RemoteStoreRawValuesTest.assertEventuallyExpires(RemoteStoreRawValuesTest.java:91) at org.infinispan.persistence.BaseStoreTest.testLoadAndStoreWithLifespanAndIdle(BaseStoreTest.java:211) 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:80) at org.testng.internal.Invoker.invokeMethod(Invoker.java:715) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237) 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$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662) {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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3648: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1021362|https://bugzilla.redhat.com/show_bug.cgi?id=1021362] This is related to https://bugzilla.redhat.com/show_bug.cgi?id=1017796 > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3648: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1021362 > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3648?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3648: ----------------------------------------------- Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1021362|https://bugzilla.redhat.com/show_bug.cgi?id=1021362] In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > Inconsistent L1 in tx distributed cache > ---------------------------------------- > > Key: ISPN-3648 > URL: https://issues.jboss.org/browse/ISPN-3648 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 6.0.0.CR1 > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > > In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. > This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3648) Inconsistent L1 in tx distributed cache

by Radim Vansa (JIRA)

Radim Vansa created ISPN-3648: --------------------------------- Summary: Inconsistent L1 in tx distributed cache Key: ISPN-3648 URL: https://issues.jboss.org/browse/ISPN-3648 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 6.0.0.CR1 Reporter: Radim Vansa Assignee: William Burns Priority: Critical In L1LastChance interceptor the CommitCommand sends invalidations only for those keys whose it is the primary owner. However, some key which is owned in backup way may be read when the command is replicated and this does not get invalidated after the command finishes. This issue is very similar to https://issues.jboss.org/browse/ISPN-3617 -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- If not, can you provide the configuration you used for the cache when you saw the problem? I am particularly interested in if it was transactional and isolation level. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3633) InvalidateL1Command during ST should not cancel writing the entry by ST

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3633?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-3633: ------------------------------------- Radim, Do you have a trace of when this happens? I have tried various scenarios of interleaving L1 invalidations with state transfer and I can't reproduce the issue yet. > InvalidateL1Command during ST should not cancel writing the entry by ST > ----------------------------------------------------------------------- > > Key: ISPN-3633 > URL: https://issues.jboss.org/browse/ISPN-3633 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache > Affects Versions: 5.3.0.Final > Reporter: Radim Vansa > Assignee: William Burns > Priority: Critical > Fix For: 6.0.0.Final > > > When a node which is about to receive the entries for some segment receives InvalidateL1Command, this puts the key into StateConsumer.updatedKeys. After the entries for ST are received, the entry which was invalidated is not updated -> this result in losing the entry. > Btw., in EntryWrappingInterceptor.visitInvalidateL1Command the trace logs all looked up entries for each entry - this causes some performance problems when tracing is on and there are many invalidated entries. Please, do this only once. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3647) GridFileSystem data becomes corrupted if file-store evication is enabled.

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3647?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3647: --------------------------------------- Hi Lincoln, there where lots of issues regarding data corruption when using CacheStores fixed during 6.0 development, I'm pretty sure it's fixed, but to narrow down the area: could you try the same test without any CacheStore ? (Assuming you don't need it for this specific test) If the issue disappears you're likely hitting one of the many issues about CacheStore inconsistency and it's then likely already fixed in WildFly (Infinispan 6.0), otherwise you might be hitting a different problem. > GridFileSystem data becomes corrupted if file-store evication is enabled. > ------------------------------------------------------------------------- > > Key: ISPN-3647 > URL: https://issues.jboss.org/browse/ISPN-3647 > Project: Infinispan > Issue Type: Bug > Components: Core API, Eviction > Affects Versions: 5.2.6.Final > Reporter: Lincoln Baxter III > Assignee: Mircea Markus > > I don't know if this is still an issue or not in the 6.x branch, but this is occurring when using the Infinispan 5.2.6 provided with EAP6.1.1 (Yes, yes, I know you should not use the provided infinispan, but it's the easiest way to get it clustered on openshift.) > This is my configuration: > {code} > <cache-container name="redoculous" aliases="ha-partition" default-cache="default" jndi-name="java:jboss/infinispan/redoculous-cluster"> > <transport/> > <replicated-cache name="filesystem.metadata" mode="SYNC" start="LAZY"> > <locking isolation="REPEATABLE_READ"/> > <eviction strategy="LIRS" max-entries="1000"/> > <file-store path="redoculous" preload="true" passivation="true"/> > </replicated-cache> > <distributed-cache name="filesystem.content" owners="2" mode="SYNC" start="LAZY"> > <locking isolation="REPEATABLE_READ"/> > <eviction strategy="LIRS" max-entries="10000"/> > <file-store path="redoculous" preload="true" passivation="true"/> > </distributed-cache> > </cache-container> > {code} > This is revealed particularly when pushing zip files to the grid. After retrieving them, upon attempt to decompress the file, ZipEntry will typically throw Exceptions about invalid entry header information, and various other sporadic issues. > I believe this is an eviction issue because typically the first few files work, but things begin to fail more and more, the more files are placed into the grid filesystem. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3647) GridFileSystem data becomes corrupted if file-store evication is enabled.

by Lincoln Baxter III (JIRA)

Lincoln Baxter III created ISPN-3647: ---------------------------------------- Summary: GridFileSystem data becomes corrupted if file-store evication is enabled. Key: ISPN-3647 URL: https://issues.jboss.org/browse/ISPN-3647 Project: Infinispan Issue Type: Bug Components: Core API, Eviction Affects Versions: 5.2.6.Final Reporter: Lincoln Baxter III Assignee: Mircea Markus I don't know if this is still an issue or not in the 6.x branch, but this is occurring when using the Infinispan 5.2.6 provided with EAP6.1.1 (Yes, yes, I know you should not use the provided infinispan, but it's the easiest way to get it clustered on openshift.) This is my configuration: {code} <cache-container name="redoculous" aliases="ha-partition" default-cache="default" jndi-name="java:jboss/infinispan/redoculous-cluster"> <transport/> <replicated-cache name="filesystem.metadata" mode="SYNC" start="LAZY"> <locking isolation="REPEATABLE_READ"/> <eviction strategy="LIRS" max-entries="1000"/> <file-store path="redoculous" preload="true" passivation="true"/> </replicated-cache> <distributed-cache name="filesystem.content" owners="2" mode="SYNC" start="LAZY"> <locking isolation="REPEATABLE_READ"/> <eviction strategy="LIRS" max-entries="10000"/> <file-store path="redoculous" preload="true" passivation="true"/> </distributed-cache> </cache-container> {code} This is revealed particularly when pushing zip files to the grid. After retrieving them, upon attempt to decompress the file, ZipEntry will typically throw Exceptions about invalid entry header information, and various other sporadic issues. I believe this is an eviction issue because typically the first few files work, but things begin to fail more and more, the more files are placed into the grid filesystem. -- 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, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2013