[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
11 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
11 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
11 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
11 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
11 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
11 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
11 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
11 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
11 years, 2 months
[JBoss JIRA] (ISPN-3635) Out of data read after write on node losing ownership
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3635?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3635 started by Pedro Ruivo.
> Out of data read after write on node losing ownership
> -----------------------------------------------------
>
> Key: ISPN-3635
> URL: https://issues.jboss.org/browse/ISPN-3635
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache, State transfer
> Affects Versions: 5.3.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 6.0.0.Final
>
>
> In a situation where a node is losing ownership of an entry (during a state transfer), when the node does a write (and commits that), the change is propagated only to the new owners, the entry is not written locally. However, when it executes read for this key afterwards, it gets the old value as this is directly retrieved from the data container.
> This bug was observed in transactional mode, but might not be limited to 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, 2 months