[
https://issues.apache.org/jira/browse/HADOOP-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
dhruba borthakur updated HADOOP-951:
------------------------------------
Attachment: jstack.27108
I saw another instance of this one. The unit test caused the namenode to to
into a 99% CPU. This thread has the FSnamesystem lock and was looping. All
datanodes timed out. The stack trace shows that thread 27163 is using all 99%
CPU and the state is "IN_JAVA". But it does not show the stack trace in detail.
I am assuming that this is another case of using a HashMap without appropriate
locking. The complete stack trace is attached here. Here is the Java bug that
explains this behaviour:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6423457
> java.util.ConcurrentModificationException in FSNamesystem.chooseTargets
> -------------------------------------------------------------------------
>
> Key: HADOOP-951
> URL: https://issues.apache.org/jira/browse/HADOOP-951
> Project: Hadoop
> Issue Type: Bug
> Components: dfs
> Affects Versions: 0.10.1
> Reporter: Koji Noguchi
> Attachments: jstack.27108
>
>
> 2007-01-26 01:14:37,509 INFO org.apache.hadoop.ipc.Server: IPC Server handler
> 7 on 8020 call error: java.io.IOException:
> java.util.ConcurrentModificationException
> java.io.IOException: java.util.ConcurrentModificationException
> at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:449)
> at java.util.AbstractList$Itr.next(AbstractList.java:420)
> at org.apache.hadoop.dfs.FSNamesystem.chooseTargets(FSNamesystem.java:2282)
> at org.apache.hadoop.dfs.FSNamesystem.startFile(FSNamesystem.java:484)
> at org.apache.hadoop.dfs.NameNode.create(NameNode.java:238)
> at sun.reflect.GeneratedMethodAccessor60.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:337)
> at org.apache.hadoop.ipc.Server$Handler.run(Server.java:538)
> Not sure if it's related, but this exception happend when namenode was
> replicating many blocks.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
