Sqoop Task using oozie workflow, ends with connection refused exception

Question

I am trying to execute sqoop task using oozie. Code structure looks like this

I have a job.properties file on my local file system, which I use to submit oozie job. Job.properties file is as follows

namenode=hdfs://servername:8020
jobtracker=servername:8021
queuename=default
oozie.wf.application.path=${namenode}/user/username/oozie

Command, I am using to submit job is

oozie job -oozie http://localhost:11000/oozie \PATH\job.properties -run

I have my workflow.xml at HDFS path as mentioned in properties application path (/user/username/oozie). With workflow.xml at HDFS folder, I have copied sqljdbc4.jar too.

Once I submit my job, I get this error in my oozie.log file.

Caused by: java.net.ConnectionException: Call to
servername/10.248.92.1:8021 failed on connection exception:

I am not sure, what is causing this exception. One weird thing is that this ip address: 10.248.92.1 is for the same server name.

Answer 1

I see you are running Hortonworks. They recently changed to the jobtracker port to 50030 by default. This gives you two options. 1) change the port to 8021 for your properties file and any other file/setting that depends on the jobtracker port or 2) change the jobtracker port back to 8021. In case you prefer option 2, here are the instructions.

The jobtracker port is not an easy setting to track down, but for HDP 1.3.2 you can find it in /usr/lib/ambari-server/web/javascripts/apps.js. Look for a block that looks like this:

{
    "name": "mapred.job.tracker",
    "templateName": ["jobtracker_host"],
    "foreignKey": null,
    "value": "<templateName[0]>:50300",
    "filename": "mapred-site.xml"
},

and change the 50300 to 8021. Unfortunately that change is not enough for the cluster to pick up the new port. Go to the Ambari Web UI and stop the MapReduce service. The go to its configuration and may a benign change (you can change it back later if you want). Once you restart MapReduce that benign change and your change to the jobtracker port will stick and you will be running on port 8021. If you are running other services that depend on the jobtracker port, go ahead and stop and restart them too.

Unfortunately you will have to do this every time you upgrade the cluster (unless Hortonworks changes how this is set up). You might want to just bite the bullet and get everything to look for the jobtracker on port 50300.

Answer 2

It means that the JobTracker is not running or not listening on port 8021 for some reason. Do a telnet servername 8021 and verify the same.