in some cases, u have to debug it in a real cluster (for example a
production problem)
in that case you need to specify the
-Xdebug -Xrunjdwp:transport=dt_socket,address=12345,server=n,suspend=n
for mapred.java.child.opts for the job (sorry forgot the exact param name,
maybe not exactly mapred.j
all right, thanks~
在 2012年7月5日星期四,Marcos Ortiz 写道:
> Jason,
> Ramon is right.
> The best way to debug a MapReduce job is mounting a local cluster, and
> then, when you have tested enough your code, then, you can
> deploy it in a real distributed cluster.
> On 07/04/2012 10:00 PM, Jason Yang wrot
Jason,
Ramon is right.
The best way to debug a MapReduce job is mounting a local cluster, and
then, when you have tested enough your code, then, you can
deploy it in a real distributed cluster.
On 07/04/2012 10:00 PM, Jason Yang wrote:
> ramon,
>
> Thank for your reply very much.
>
> However, I was
ramon,
Thank for your reply very much.
However, I was still wonder whether I could debug a MR application in this
way.
I have read some posts talking about using NAT to redirect all the packets
to the network card which connect to the local LAN, but it does not work as
I tried to redirect by usi
Jason,
the easiest way to debug a MapRedupe program with eclipse is working on
hadoop local. http://hadoop.apache.org/common/docs/r0.20.2/quickstart.html#Local
In this mode all the components run locally on the same VM and can be easily
debugged using Eclipse.
Hope this will be useful.
From: