[
https://issues.apache.org/jira/browse/HADOOP-8157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Todd Lipcon updated HADOOP-8157:
--------------------------------
Attachment: hadoop-8157.txt
I believe the problem is this:
The cache added by HADOOP-6502 used a "null" value in the map as a negative
cache entry for a class not found. However, it uses a WeakHashMap to avoid
leaking references. The semantics of WeakHashMap are such that we could hit the
following scenario:
- check "containsKey()" for a given key, see it was there
- GC runs and clears that key from the map
- call "get" and return null.
- Now we think it was a negative cache entry and throw ClassNotFoundException
The fix here is to stop using nulls to cache the "not found" result. Instead,
we insert a special sentinel value as a negative cache entry.
Unfortunately it's diffcult to reproduce this on my box, but we've seen
TestRPCCallBenchmark fail on Hudson a lot without this patch. So if we commit
this, and we stop seeing the failures, we'll know we fixed the bug.
> TestRPCCallBenchmark#testBenchmarkWithWritable fails with RTE
> -------------------------------------------------------------
>
> Key: HADOOP-8157
> URL: https://issues.apache.org/jira/browse/HADOOP-8157
> Project: Hadoop Common
> Issue Type: Test
> Affects Versions: 0.24.0
> Reporter: Eli Collins
> Assignee: Todd Lipcon
> Attachments: hadoop-8157.txt
>
>
> Saw TestRPCCallBenchmark#testBenchmarkWithWritable fail with the following on
> jenkins:
> Caused by: java.lang.RuntimeException: IPC server unable to read call
> parameters: readObject can't find class java.lang.String
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
