Thursday, 9 March 2017


Hue Unable to retrieve logs when executing Hive query from Hue editor


Issue

Hue Unable to retrieve logs when executing Hive query from Hue editor. Hue version is 3.9 and Hive version is 1.2. In the Hue UI, it throws ‘Invalid method name: 'GetLog'’ error.

Error in runscpserver.log


TApplicationException: Invalid method name: 'GetLog'
[09/Mar/2017 14:39:04 -0800] thrift_util  INFO     Thrift saw an application exception: Invalid method name: 'GetLog'
[09/Mar/2017 14:39:04 -0800] hive_server2_lib ERROR    server does not support GetLog
Traceback (most recent call last):
  File "/opt/mapr/hue/hue-3.9.0/apps/beeswax/src/beeswax/server/hive_server2_lib.py", line 750, in get_log
    res = self.call(self._client.GetLog, req)
  File "/opt/mapr/hue/hue-3.9.0/apps/beeswax/src/beeswax/server/hive_server2_lib.py", line 555, in call
    res = fn(req)
  File "/opt/mapr/hue/hue-3.9.0/desktop/core/src/desktop/lib/thrift_util.py", line 377, in wrapper
    raise StructuredException('THRIFTAPPLICATION', str(e), data=None, error_code=502

Solution


Check whether ‘use_get_log_api’ is set to ‘true’ in hue.ini file. Comment it out or make it ‘false’ and restart Hue.

Wednesday, 8 March 2017


Configuring HBase Thrift HA in MapR Clusters


AIM

Make HBase thrift HA with multiple thrift servers as ACTIVE.

Default behavior

If we have hbase thrift installed in to nodes, one will be shown as active and the other as standby.

Steps


Make changes in following file in all the hbase thrift server nodes

/opt/mapr/conf/conf.d/warden.hbasethrift.conf
#
# sed -i s/\1.1.1/`cat /opt/mapr/hbase/hbaseversion`/g /opt/mapr/conf/conf.d/warden.hbasethrift.conf
#
services=hbasethrift:all
service.displayname=HBaseThriftServer
service.command.start=/opt/mapr/hbase/hbase-1.1.1/bin/hbase-daemon.sh start thrift
service.command.stop=/opt/mapr/hbase/hbase-1.1.1/bin/hbase-daemon.sh stop thrift
service.command.type=BACKGROUND
service.command.monitorcommand=/opt/mapr/hbase/hbase-1.1.1/bin/hbase-daemon.sh status thrift
service.port=9090
service.ui.port=9095
service.logs.location=/opt/mapr/hbase/hbase-1.1.1/logs
service.process.type=JAVA
service.alarm.tersename=hbasethrift
service.alarm.label=HbaseThriftServiceDown


Once the changes are made, restart warden in all nodes

service mapr-warden restart

Once the warden comes up, you will see all the thrift servers in active state.

I have installed hbase thrift in 2 nodes. Below MCS screenshot shows that hbase thrift is up and running in two nodes.





Wednesday, 1 March 2017


Oozie workflow shows in running state even after job is completed successfully


Issue:


Oozie workflow shows to be in running state even after the job has completed successfully. oozie job -info <workflow_ID> will show that job has completed successfully. However in web UI it still remains as running.
If we try to kill the workflow in oozie using oozie job -kill <workflow_ID>, it will throw the following error:

Error: E0607 : E0607: Other error in operation [kill], java.io.EOFException

In the oozie.log you can find following exception: (exception captured while trying to suspend the job)

2017-03-01 15:10:59,753  WARN V2JobServlet:523 - SERVER[phpvcoredev03.chicago.local] USER[vcoredevuser] GROUP[-] TOKEN[] APP[Lab-EdwardLabResults] JOB[0000237-160624170341227-oozie-mapr-W] ACTION[] URL[PUT http://phpvcoredev03:11000/oozie/v2/job/0000237-160624170341227-oozie-mapr-W?action=suspend] error[E0607], E0607: Other error in operation [suspend], java.io.EOFException
org.apache.oozie.servlet.XServletException: E0607: Other error in operation [suspend], java.io.EOFException
        at org.apache.oozie.servlet.V1JobServlet.suspendWorkflowJob(V1JobServlet.java:430)
        at org.apache.oozie.servlet.V1JobServlet.suspendJob(V1JobServlet.java:127)
        at org.apache.oozie.servlet.BaseJobServlet.doPut(BaseJobServlet.java:92)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:646)
        at org.apache.oozie.servlet.JsonRestServlet.service(JsonRestServlet.java:304)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:723)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.oozie.servlet.AuthFilter$2.doFilter(AuthFilter.java:171)
        at org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:604)
        at org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:567)
        at org.apache.oozie.servlet.AuthFilter.doFilter(AuthFilter.java:176)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.oozie.servlet.HostnameFilter.doFilter(HostnameFilter.java:86)
        at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
        at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
        at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
        at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
        at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
        at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
        at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)

Resolution:


Delete the job from the oozie database.
The entry must be deleted from both WF_JOBS and WF_ACTIONS table.

HBase replication stops abruptly


Issue: 

HBase replication between source and DR cluster stops abruptly. Replication will not happen for existing tables, however replication will work as expected for newly created tables. All the necessary configuration for replication is specified correctly. The HBase services are up and running.


Root cause:

When a regionserver crashes, a different regionserver will try to take over the hlogs queue from the crashed regionserver to finish the replication activity. This will create a persistent zk node named "lock". This will help other regionservers to take over the replication queue again.

public boolean lockOtherRS(String znode) {
    try {
      String parent = ZKUtil.joinZNode(this.rsZNode, znode);
      if (parent.equals(rsServerNameZnode)) {
        LOG.warn("Won't lock because this is us, we're dead!");
        return false;
      }
      String p = ZKUtil.joinZNode(parent, RS_LOCK_ZNODE);
      ZKUtil.createAndWatch(this.zookeeper, p, Bytes.toBytes(rsServerNameZnode));
    } catch (KeeperException e) {
      ...
      return false;
    }
    return true;
  }


If the 'hbase.zookeeper.useMulti​' in hbase-site.xml is set to 'false', then if the regionserver crashes after creating the lock and before copying the replication queue of previously crashed server to its replication queue, the "lock" will not be deleted and no other regionserver can take over the replication queue.


Symptoms in HBase regionserver logs: (DR cluster)

2017-02-14 14:37:36,109 INFO  [ReplicationExecutor-0] replication.ReplicationQueuesZKImpl: Won't transfer the queue, another RS took care of it because of: KeeperErrorCode = NodeExists for /hbase/replication/rs/xxxx.com,60020,1469048347755/lock


Resolution:

The solution is setting hbase.zookeeper.useMulti=true in hbase-site.xml.
Remove the /hbase/replication/rs from the DR cluster.


Installing Ganglia on MapR to monitor HBase


Node details:

Node1 – 10.10.YY.X1
Node2 - 10.10.YY.X2
Node3 - 10.10.YY.X3

 The basic packages required for ganglia to run are:

[1] ganglia-gmond – required on all nodes from where metrics needs to be collected
[2] ganglia-gmetad – required on node which will perform aggregation (typically on one node)
[3] ganglia-web – required on the node running the Ganglia web UI

Following is my setup: (Concentrating on Ganglia and HBase)

Node1 – 10.10.YY.X1 – Hbase regionserver, gmond
Node2 - 10.10.YY.X3 – Hbase regionserver, gmond
Node3 - 10.10.YY.X2 – Hbase regionserver, Hbase master, gmond, gemetad, ganglia-web

For installing the packages in CentOS, use the following command:

yum install ganglia-gmond -y
yum install ganglia-gmetad -y
yum install ganglia-web -y

Edit ‘/etc/ganglia/gmond.conf’ on all nodes running the gmond service (sample is shown below)

Part 1:
cluster {
  name = "ThreeNodeClusterAJames"
  owner = "unspecified"
  latlong = "unspecified"
  url = "unspecified"
}

Part 2:
udp_send_channel {
  bind_hostname = yes # Highly recommended, soon to be default.
                       # This option tells gmond to use a source address
                       # that resolves to the machine's hostname.  Without
                       # this, the metrics may appear to come from any
                       # interface and the DNS names associated with
                       # those IPs will be used to create the RRDs.
  #mcast_join = 239.2.11.71
  host = 10.10.YY.XX
  port = 8649
  ttl = 1
}

NOTE:
·        We are using unicast protocol instead of multicast protocol. Please comment ‘mcast_join = 239.2.11.71’ and add “host = <IP of localhost running the gmond service>”
·        If there is any change in the port used, please change the same in ‘port’ property. Here I am using the default port which is 8649.

Part 3:
udp_recv_channel {
  #mcast_join = 239.2.11.71
  port = 8649
  #bind = 239.2.11.71
  #bind = 10.10.72.154
  #retry_bind = true
  # Size of the UDP buffer. If you are handling lots of metrics you really
  # should bump it up to e.g. 10MB or even higher.
  # buffer = 10485760
}

Edit ‘/etc/ganglia/gmetad.conf’ in gmetad server and add the following:

data_source "ThreeNodeClusterAJames" 10.10.YY.X1:8649 10.10.YY.X2:8649 10.10.YY.X3:8649

The cluster name ‘ThreeNodeClusterAJames’ should be same in all the gmond servers and gmetad server.

Edit ‘/opt/mapr/conf/hadoop-metrics.properties’ file and add

Part 1:
# Configuration of the "cldb" context for ganglia
cldb.class=com.mapr.fs.cldb.counters.MapRGangliaContext31
cldb.period=10
cldb.servers=10.10.YY.X1:8649,10.10.YY.X2:8649,10.10.YY.X3:8649
cldb.spoof=1

Part 2:
# Configuration of the "fileserver" context for ganglia
fileserver.class=com.mapr.fs.cldb.counters.MapRGangliaContext31
fileserver.period=37
fileserver.servers=10.10.YY.X1:8649,10.10.YY.X2:8649,10.10.YY.X3:8649
fileserver.spoof=1

Execute the following in any of the node and restart cldb service on all cldb nodes:

maprcli config save -values {"cldb.ganglia.cldb.metrics":"1"}
maprcli config save -values {"cldb.ganglia.fileserver.metrics":"1"}

 Execute the following in all nodes

sudo setenforce 0

Execute the following gmetad server:

chown -R apache:apache /usr/share/ganglia
chown -R ganglia:ganglia /var/lib/ganglia/rrd*
chcon -R -t httpd_sys_content_t *

Edit ‘/etc/httpd/conf.d/ganglia.conf’ file:

<Location /ganglia>
  Order deny,allow
#  Deny from all
  Allow from 127.0.0.1
  Allow from ::1
  # Allow from .example.com
</Location>

Restart the httpd, gmond and gmetad:

/etc/init.d/httpd restart
/etc/init.d/gmond restart
/etc/init.d/httpd restart

Edit ‘/opt/mapr/hbase/hbase-<version>/conf/hadoop-metrics2-hbase.properties’ file

hbase.sink.ganglia.class=org.apache.hadoop.metrics2.sink.ganglia.GangliaSink31
hbase.sink.ganglia.servers=<ganglia-server>:8649
hbase.sink.ganglia.period=10

hbase.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
hbase.period=10
hbase.servers=<server-running-hbase-regionserver-1>:8649, <server-running-hbase-regionserver-2>:8649

# Configuration of the "jvm" context for ganglia
# Pick one: Ganglia 3.0 (former) or Ganglia 3.1 (latter)
# jvm.class=org.apache.hadoop.metrics.ganglia.GangliaContext
jvm.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
jvm.period=10
jvm.servers=<server-running-hbase-regionserver-1>:8649, <server-running-hbase-regionserver-2>:8649
...
# Configuration of the "rpc" context for ganglia
# Pick one: Ganglia 3.0 (former) or Ganglia 3.1 (latter)
# rpc.class=org.apache.hadoop.metrics.ganglia.GangliaContext
rpc.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
rpc.period=10
rpc.servers=<server-running-hbase-regionserver-1>:8649, <server-running-hbase-regionserver-2>:8649
...
# Configuration of the "rest" context for ganglia
# Pick one: Ganglia 3.0 (former) or Ganglia 3.1 (latter)
# rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext
rest.class=org.apache.hadoop.metrics.ganglia.GangliaContext31
rest.period=10
rest.servers=<server-running-hbase-regionserver-1>:8649, <server-running-hbase-regionserver-2>:8649

Restart Hbase master and regionserver in all nodes.
You should be able to see the hbase metrics in ganglia web UI.


Ganglia UI listing the metrics collected:



Ganglia UI showing HBase metrics:



Tuesday, 21 February 2017



Enabling ODBC driver log for MapR DRILL


Following steps help you to set ODBC driver log to TRACE level. 
Edit file '.mapr.drillodbc.ini' which should be present in the HOME directory.
Set 'LogLevel' to 6 and mention the path to where log will be written in 'LogPath'.

Example:
[Driver]
LogLevel=6
LogPath=/tmp/

Once this is set, we will start to see two log fles
driver.log
drillclient<timestamp>.log

Friday, 16 December 2016

Connectivity issue with Tableau 10 and MapR DRILL


If you are hitting connectivity issue with Tableau and DRILL with following symptoms, you are probably hitting a bug in Tableau 10.0.1/10.0.2.

Symptoms:

[1] You will see following error when you try to connect 10.0.1/10.0.2 with DRILL with authentication



[2] There will be no issue in connecting Tableau to non-authenticated DRILL.  
[3] No issue with DRILL EXPLORER to connect to either authenticated or non-authenticated DRILL BITS. 

Fix:

The issue is fixed in Tableau 10.0.3.

Workaround:

Following are the other workarounds:

[1] Try running tableau using command line with command "tableau.exe -DProtocolServerReconnect=1" and see if you are able to connect to driver. The easiest way in windows is to set the properties for a desktop shortcut by adding -DProtocolServerReconnect=1 after the double quotes pointing to the tableau.exe file.




[2] Second way is to make sure that when you try to connect to your driver DSN from tableau, you are not prompted with a connection dialog i.e. you set values for all the driver keys in windows registry. 

The issue is observed in case user is presented with connection dialog while connecting to driver from tableau. So, the fix is to suppress this connection dialog. When we try to connect to ODBC data sources from tableau, we can either choose to connect to DSN or Driver. If connect using driver is selected, then connection dialog is always presented and connection fails for some drivers.
If we try to connect using DSN then we can suppress connection dialog by setting all connection properties in windows registry. The connection properties can be set under the registry path: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\ [Driver DSN]