drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jinfeng Ni <jinfengn...@gmail.com>
Subject Re: Question re "obscure" Drill scripts
Date Wed, 22 Jun 2016 00:53:39 GMT
For the obscure scripts:

dumpcat : I do not think it's used any more.
submit-plan: It was once used to submit logical / physical plan to
drillbit before Drill has SQL support. Personally, I have not used
this script for long time. Not sure if Web-UI (which has a
functionality to submit logical/physical plan) need this or not.

On Tue, Jun 21, 2016 at 5:07 PM, Paul Rogers <progers@maprtech.com> wrote:
> As a follow up…
> I’d still appreciate hints for the “obscure” scripts.
> I propose to make a change to the four sqlline scripts. Today, the sqlline scripts use
the same memory settings as the drillbit. This can lead to overly heavy client processes.
The change is:
> The three client scripts (sqlline, drill-local, drill-conf) will use client-only configuration
options (especially for memory.)
> The embedded script (drill-embedded) will continue use the Drillbit memory options (heavy
heap, direct memory and code cache.)
> This change will be transparent to users.
> Anything I’m missing? Do we need the heavy heap & direct memory when the Drill
code acts only as a client?
> Thanks,
> - Paul
>> On Jun 21, 2016, at 11:48 AM, Paul Rogers <progers@maprtech.com> wrote:
>> Hi All,
>> The Drill-on-YARN (DoY) stuff will include some much-needed clean-up of the Drill
scripts in $DRILL_HOME/bin, so I need to retest all the scripts. Three scripts seem pretty
obscure. But, let’s start with the known ones.
>> The “primary” scripts seem to be:
>> drillbit.sh — User command to start/stop/monitor a Drill daemon
>> drill-config.sh — Internal script to set up the Drill launch environment.
>> runbit — Internal script to build up the Java command line for a drillbit and run
>> sqlline — User script to launch SqlLine.
>> One question that immediately pops to mind: why do some scripts use “.sh” and
some not? One could argue that user-commands should omit the .sh as sqlline does. But drillbit.sh
uses .sh. And, the purely internal drill-config.sh and runbit made opposing choices… Just
an artifact, or is there some subtle pattern?
>> There are various wrappers around sqlline as described in the Apache Drill docs:
https://drill.apache.org/docs/starting-drill-in-distributed-mode/ and https://drill.apache.org/docs/starting-drill-on-linux-and-mac-os-x/
>> drill-conf — Wrapper for sqlline, uses drill config to find Drill. Seems this one
needs fixing to use a config other than the hard-coded $DRILL_HOME/conf location.
>> drill-embedded — Starts a drill “embedded” in SqlLine, using a local ZK.
>> drill-localhost — Wrapper for sqlline, uses a local ZK.
>> Then there are three very obscure scripts. What do these do, and, more importantly,
are they still used?
>> drillbit — Appears to be a analog of drillbit.sh, but seems patterned for some
system with which I’m not familiar. It also assumes Drill is installed in /opt/drill. Any
>> dumpcat — Runs an undocumented DumpCat Java class. The only mentions of this on
Apache Drill are two JIRA entries.
>> submit-plan — Appears to directly submit a physical plan. Documented only in a
JIRA: https://issues.apache.org/jira/browse/DRILL-2107
>> Thanks,
>> - Paul

View raw message