hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "dhruba borthakur (JIRA)" <j...@apache.org>
Subject [jira] Updated: (HADOOP-951) java.util.ConcurrentModificationException in FSNamesystem.chooseTargets
Date Mon, 05 Feb 2007 21:27:05 GMT

     [ 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:


>  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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message