[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
12 years, 2 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097]
No, we don't have functional tests that could highlight this issue. We haven't seen any issues when running performance tests for queries, but I'm not sure we ran any perf. tests at the moment the problem was there.
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {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, 2 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Sanne Grinovero <sanne(a)redhat.com> made a comment on [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097]
I'm wondering if QA actually already had tests which could highlight this?
In Infinispan running the functional testsuite is not enough, you need to run a load or performance test to trigger the failure.
I'm pretty confident that it will pass QA now but it would be good to verify that the version without the fix was actually causing some failure.
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {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, 2 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097] from MODIFIED to ON_QA
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {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, 2 months
[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3617:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 1017796|https://bugzilla.redhat.com/show_bug.cgi?id=1017796]
Fixed in ER3.1
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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, 2 months
[JBoss JIRA] (ISPN-3592) Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3592?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3592:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 1018097|https://bugzilla.redhat.com/show_bug.cgi?id=1018097]
Fixed in ER3.1
> Regression in Lucene Directory: NPE during SegmentInfos.getLastCommitGeneration
> -------------------------------------------------------------------------------
>
> Key: ISPN-3592
> URL: https://issues.jboss.org/browse/ISPN-3592
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.CR1
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Priority: Blocker
> Fix For: 6.0.0.Final
>
>
> The problem is a very recent regression, so relative to 6.0.0.CR1 only.
> {noformat}
> java.lang.NullPointerException
> at org.apache.lucene.index.SegmentInfos.getLastCommitGeneration(SegmentInfos.java:160)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:605)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.SegmentInfos.readCurrentVersion(SegmentInfos.java:483)
> at org.apache.lucene.index.DirectoryReader.isCurrent(DirectoryReader.java:891)
> at org.apache.lucene.index.DirectoryReader.doOpenNoWriter(DirectoryReader.java:455)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:434)
> at org.apache.lucene.index.DirectoryReader.doOpenIfChanged(DirectoryReader.java:375)
> at org.apache.lucene.index.IndexReader.openIfChanged(IndexReader.java:508)
> at org.apache.lucene.index.IndexReader.reopen(IndexReader.java:695)
> at org.infinispan.lucene.profiling.LuceneReaderThread.refreshIndexReader(LuceneReaderThread.java:58)
> {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, 2 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3603:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1016499|https://bugzilla.redhat.com/show_bug.cgi?id=1016499] from MODIFIED to ON_QA
> Conditional command is committed on originator when it fails on primary owner
> -----------------------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
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, 2 months
[JBoss JIRA] (ISPN-3603) Conditional command is committed on originator when it fails on primary owner
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3603?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3603:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug 1016499|https://bugzilla.redhat.com/show_bug.cgi?id=1016499]
Fixed in ER3.1
> Conditional command is committed on originator when it fails on primary owner
> -----------------------------------------------------------------------------
>
> Key: ISPN-3603
> URL: https://issues.jboss.org/browse/ISPN-3603
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> In non-tx cache, when conditional command (e.g. ReplaceCommand) fails on primary owner because the old value is not equal to current value, the NonTxDistributionInterceptor.visitReplaceCommand returns false but the entry is committed in EntryWrappingInterceptor anyway.
> Speaking about EntryWrappingInterceptor.invokeNextAndApplyChanges: NonTxDistributionInterceptor does not mark the command as unsuccessful if it fails on the primary owner, therefore, checking for command.isSuccessful() in order to retry the command upon topology change may seem insufficient.
--
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, 2 months
[JBoss JIRA] (ISPN-3617) Inconsistent L1 in non-tx distributed cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3617:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1017796|https://bugzilla.redhat.com/show_bug.cgi?id=1017796] from MODIFIED to ON_QA
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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, 2 months
[JBoss JIRA] (ISPN-3646) org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3646?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3646:
--------------------------------
Assignee: William Burns (was: Mircea Markus)
> org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3646
> URL: https://issues.jboss.org/browse/ISPN-3646
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Environment: Windows 2008R2 & Windows 2012, JDK7
> Reporter: Anna Manukyan
> Assignee: William Burns
> Labels: testsuite_stability
>
> The test org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails constantly on windows machines with the following error:
> java.lang.AssertionError: expected:<some-new-value> but was:<some-value>
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
> at org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update(DistSyncL1PessimisticFuncTest.java:90)
> 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: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.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:724)
--
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, 2 months