[
https://issues.apache.org/jira/browse/PHOENIX-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14943086#comment-14943086
]
ASF GitHub Bot commented on PHOENIX-2256:
-----------------------------------------
Github user chiastic-security commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/118#discussion_r41122346
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/schema/PMetaDataImpl.java ---
@@ -160,7 +160,7 @@ public PMetaDataCache cloneMinusOverage(long overage) {
newCache.put(tableRef.table.getKey(), new
PTableRef(tableRef));
toRemove.add(tableRef);
toRemoveBytes += tableRef.estSize;
- if (toRemoveBytes - toRemove.peekLast().estSize >
overage) {
+ while (toRemoveBytes - toRemove.peekLast().estSize >=
overage) {
--- End diff --
I've added a couple more tests.
The `cloneMinusOverage()` method does sometimes need to clear everything
out, because it's what happens prior to adding the new thing, so it's correct
for it not to break out of the loop when the size is one. I've added a test to
confirm this (`shouldAlwaysKeepAtLeastOneEntryEvenIfTooLarge()`).
I've also added a test to check things work out OK when the max size is
zero. In this case there should always be exactly one thing in the cache (after
the first item has been added). This test also passes.
> Test failure in PMetaDataImplTest
> ---------------------------------
>
> Key: PHOENIX-2256
> URL: https://issues.apache.org/jira/browse/PHOENIX-2256
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.6.0
> Environment: Happens on both Ubuntu and Fedora, running 64-bit Java 8.
> Reporter: James Heather
>
> f I make a fresh clone of the repo, and then run mvn package, I get a test
> failure:
> {code}
>
> -------------------------------------------------------------------------------
> Test set: org.apache.phoenix.schema.PMetaDataImplTest
>
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.027 sec
> <<< FAILURE! - in org.apache.phoenix.schema.PMetaDataImplTest
> testEviction(org.apache.phoenix.schema.PMetaDataImplTest) Time elapsed:
> 0.027 sec <<< FAILURE!
> java.lang.AssertionError: expected:<3> but was:<2>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.phoenix.schema.PMetaDataImplTest.testEviction(PMetaDataImplTest.java:98)
> {code}
> This appears to be a bug in {{PMetaDataImpl.java}}. The test looks right.
> Table {{b}} should get evicted first, which creates enough space for {{d}}.
> But in fact {{c}} gets evicted first, and then {{b}} needs to be evicted as
> well to make enough room.
> I don't know if there's a race condition in here somewhere. It's odd that no
> one has picked up on a failing test before, so I'm wondering whether it
> succeeds in some environments. But it fails for me on both Ubuntu and Fedora
> (both with 64-bit Java 8).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
