Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
None
Description
Using -Dgiraph.SplitMasterWorker=false with a recent trunk (r1401165) caused the machine who is playing the master role (showing itself as ALL from the task tracker page) to throw ClassCastException (SendVertexRequest -> MasterRequest) from MasterRequestServerHandler class. I'm trying to use as many machines as possible for actual computation (can't afford to waste one for master+ZK). This worked fine with r1388628 (roughly a month ago), so a recent change must've broken something. Here's the relevant log I captured:
2012-10-24 23:08:02,152 WARN org.apache.giraph.comm.netty.handler.RequestServerHandler: exceptionCaught: Channel failed with remote address /10.x.y.z:41780 java.lang.ClassCastException: org.apache.giraph.comm.requests.SendVertexRequest cannot be cast to org.apache.giraph.comm.requests.MasterRequest at org.apache.giraph.comm.netty.handler.MasterRequestServerHandler.processRequest(MasterRequestServerHandler.java:25) at org.apache.giraph.comm.netty.handler.RequestServerHandler.messageReceived(RequestServerHandler.java:100) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) at org.jboss.netty.handler.codec.oneone.OneToOneDecoder.handleUpstream(OneToOneDecoder.java:71) at org.jboss.netty.handler.execution.ChannelUpstreamEventRunnable.doRun(ChannelUpstreamEventRunnable.java:45) at org.jboss.netty.handler.execution.ChannelEventRunnable.run(ChannelEventRunnable.java:69) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662)
Attachments
Attachments
Issue Links
- relates to
-
GIRAPH-362 Address master task id for communication for master (known issue from GIRAPH-211)
- Open