[jira] [Created] (HIVE-16172) Switch to a fairness lock to synchronize HS2 thrift client

[Tao Li (JIRA)]

Tao Li created HIVE-16172:
-

 Summary: Switch to a fairness lock to synchronize HS2 thrift client
 Key: HIVE-16172
 URL: https://issues.apache.org/jira/browse/HIVE-16172
 Project: Hive
  Issue Type: Bug
Reporter: Tao Li
Assignee: Tao Li






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16171) Support truncate table for replication

[Sankar Hariappan (JIRA)]

Sankar Hariappan created HIVE-16171:
---

 Summary: Support truncate table for replication
 Key: HIVE-16171
 URL: https://issues.apache.org/jira/browse/HIVE-16171
 Project: Hive
  Issue Type: Sub-task
  Components: repl
Reporter: Sankar Hariappan
Assignee: Sankar Hariappan


Need to support truncate table for replication. Key points to note.
1. For non-partitioned table, truncate table doesn't make any sense as only 
drop table shall delete the data.
2. For partitioned tables, need to consider how truncate behaves if drop a 
partition or rename the partition or so.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16170) Exclude relocation of org.apache.hadoop.security.* in the JDBC standalone jar

[Tao Li (JIRA)]

Tao Li created HIVE-16170:
-

 Summary: Exclude relocation of org.apache.hadoop.security.* in the 
JDBC standalone jar
 Key: HIVE-16170
 URL: https://issues.apache.org/jira/browse/HIVE-16170
 Project: Hive
  Issue Type: Bug
Reporter: Tao Li
Assignee: Tao Li


There has been a use case that core-site.xml file is used along with the JDBC 
jar, which sets "hadoop.security.group.mapping" using the class names such as 
"org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback". This will 
cause CNF errors due to the renaming. So we need to exclude those security 
related classes in the relocation part.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16169) Improve StatsOptimizer to deal with groupby partition columns

[Pengcheng Xiong (JIRA)]

Pengcheng Xiong created HIVE-16169:
--

 Summary: Improve StatsOptimizer to deal with groupby partition 
columns
 Key: HIVE-16169
 URL: https://issues.apache.org/jira/browse/HIVE-16169
 Project: Hive
  Issue Type: Bug
Reporter: Pengcheng Xiong
Assignee: Pengcheng Xiong


As reported by [~ashutoshc]
1) select sum(c), count(c),... from T group by b;
2) select max(c), min(c), ... from T group by b;
If b happens to be a partition column, we can also answer these from metadata.  
Currently, StatsOptimizer don't handle these queries, but we can extend it to 
handle those as well.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16168) llap log links should use the NM nodeId port instead of web port

[Siddharth Seth (JIRA)]

Siddharth Seth created HIVE-16168:
-

 Summary: llap log links should use the NM nodeId port instead of 
web port
 Key: HIVE-16168
 URL: https://issues.apache.org/jira/browse/HIVE-16168
 Project: Hive
  Issue Type: Bug
  Components: llap
Reporter: Siddharth Seth
Assignee: Siddharth Seth






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16167) Remove transitive dependency on mysql connector jar

[Ashutosh Chauhan (JIRA)]

Ashutosh Chauhan created HIVE-16167:
---

 Summary: Remove transitive dependency on mysql connector jar
 Key: HIVE-16167
 URL: https://issues.apache.org/jira/browse/HIVE-16167
 Project: Hive
  Issue Type: Bug
  Components: Build Infrastructure, Druid integration
Reporter: Ashutosh Chauhan
Assignee: Ashutosh Chauhan


Brought in by druid storage handler transitively.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16166) HS2 may still waste up to 15% of memory on duplicate strings

[Misha Dmitriev (JIRA)]

Misha Dmitriev created HIVE-16166:
-

 Summary: HS2 may still waste up to 15% of memory on duplicate 
strings
 Key: HIVE-16166
 URL: https://issues.apache.org/jira/browse/HIVE-16166
 Project: Hive
  Issue Type: Improvement
Reporter: Misha Dmitriev
Assignee: Misha Dmitriev


A heap dump obtained from one of our users shows that 15% of memory is wasted 
on duplicate strings, despite the recent optimizations that I made. The 
problematic strings just come from different sources this time. See the excerpt 
from the jxray (www.jxray.com) analysis attached.

Adding String.intern() calls in the appropriate places reduces the overhead of 
duplicate strings with this workload to ~6%. The remaining duplicates come 
mostly from JDK internal and MapReduce data structures, and thus are more 
difficult to fix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16165) use database broken on master

[Siddharth Seth (JIRA)]

Siddharth Seth created HIVE-16165:
-

 Summary: use database broken on master
 Key: HIVE-16165
 URL: https://issues.apache.org/jira/browse/HIVE-16165
 Project: Hive
  Issue Type: Bug
Affects Versions: 2.2.0
Reporter: Siddharth Seth
Priority: Blocker


{code}
2017-03-09T19:37:20,765  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Starting Semantic Analysis
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Completed phase 1 of Semantic Analysis
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Get metadata for source tables
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Get metadata for subqueries
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Get metadata for destination tables
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.CalcitePlanner: Completed getting MetaData in Semantic Analysis
2017-03-09T19:37:20,766  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
parse.BaseSemanticAnalyzer: Not invoking CBO because the statement doesn't have 
QUERY or EXPLAIN as root and not a CTAS; is not a query with at least one 
source table  or there is a subquery without a source table, or CTAS, or insert
2017-03-09T19:37:20,810  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
ql.Context: New scratch dir is 
hdfs://cn105-10.l42scl.hortonworks.com:8020/tmp/hive/sseth/9171ecb2-4f38-4254-8138-f78a73c24181/hive_2017-03-09_19-37-20_763_6998351573308778636-1
2017-03-09T19:37:20,894  INFO [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
ppd.OpProcFactory: Processing for TS(0)
2017-03-09T19:37:20,900 ERROR [9171ecb2-4f38-4254-8138-f78a73c24181 main] 
ql.Driver: FAILED: NullPointerException null
java.lang.NullPointerException
at 
org.apache.hadoop.hive.ql.stats.StatsUtils.estimateRowSizeFromSchema(StatsUtils.java:543)
at 
org.apache.hadoop.hive.ql.stats.StatsUtils.getNumRows(StatsUtils.java:180)
at 
org.apache.hadoop.hive.ql.stats.StatsUtils.collectStatistics(StatsUtils.java:204)
at 
org.apache.hadoop.hive.ql.stats.StatsUtils.collectStatistics(StatsUtils.java:154)
at 
org.apache.hadoop.hive.ql.stats.StatsUtils.collectStatistics(StatsUtils.java:142)
at 
org.apache.hadoop.hive.ql.optimizer.stats.annotation.StatsRulesProcFactory$TableScanStatsRule.process(StatsRulesProcFactory.java:130)
at 
org.apache.hadoop.hive.ql.lib.DefaultRuleDispatcher.dispatch(DefaultRuleDispatcher.java:90)
at 
org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.dispatchAndReturn(DefaultGraphWalker.java:105)
at 
org.apache.hadoop.hive.ql.lib.DefaultGraphWalker.dispatch(DefaultGraphWalker.java:89)
at 
org.apache.hadoop.hive.ql.lib.LevelOrderWalker.walk(LevelOrderWalker.java:143)
at 
org.apache.hadoop.hive.ql.lib.LevelOrderWalker.startWalking(LevelOrderWalker.java:122)
at 
org.apache.hadoop.hive.ql.optimizer.stats.annotation.AnnotateWithStatistics.transform(AnnotateWithStatistics.java:78)
at 
org.apache.hadoop.hive.ql.parse.TezCompiler.runStatsAnnotation(TezCompiler.java:302)
at 
org.apache.hadoop.hive.ql.parse.TezCompiler.optimizeOperatorPlan(TezCompiler.java:96)
at 
org.apache.hadoop.hive.ql.parse.TaskCompiler.compile(TaskCompiler.java:140)
at 
org.apache.hadoop.hive.ql.parse.SemanticAnalyzer.analyzeInternal(SemanticAnalyzer.java:11174)
at 
org.apache.hadoop.hive.ql.parse.CalcitePlanner.analyzeInternal(CalcitePlanner.java:285)
at 
org.apache.hadoop.hive.ql.parse.BaseSemanticAnalyzer.analyze(BaseSemanticAnalyzer.java:258)
at org.apache.hadoop.hive.ql.Driver.compile(Driver.java:511)
at org.apache.hadoop.hive.ql.Driver.compileInternal(Driver.java:1316)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1456)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1236)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1226)
at 
org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:233)
at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:184)
at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:403)
at 
org.apache.hadoop.hive.cli.CliDriver.executeDriver(CliDriver.java:821)
at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:759)
at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:686)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
  

Re: Review Request 57405: HIVE-16104 LLAP: preemption may be too aggressive if the pre-empted task doesn't die immediately

[Sergey Shelukhin]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57405/#review168563
---




llap-server/src/java/org/apache/hadoop/hive/llap/daemon/impl/TaskExecutorService.java
Line 91 (original), 91 (patched)


should be changed to 500, will change in the jira patch, and next revision 
here if any


- Sergey Shelukhin


On March 10, 2017, 12:20 a.m., Sergey Shelukhin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57405/
> ---
> 
> (Updated March 10, 2017, 12:20 a.m.)
> 
> 
> Review request for hive and Siddharth Seth.
> 
> 
> Repository: hive-git
> 
> 
> Description
> ---
> 
> see jira
> 
> 
> Diffs
> -
> 
>   
> llap-server/src/java/org/apache/hadoop/hive/llap/daemon/impl/TaskExecutorService.java
>  c1f6c96 
>   
> llap-server/src/java/org/apache/hadoop/hive/llap/daemon/impl/TaskRunnerCallable.java
>  18f0db9 
>   
> llap-server/src/test/org/apache/hadoop/hive/llap/daemon/impl/TestTaskExecutorService.java
>  bf7d1d8 
> 
> 
> Diff: https://reviews.apache.org/r/57405/diff/4/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sergey Shelukhin
> 
>

Re: Review Request 57405: HIVE-16104 LLAP: preemption may be too aggressive if the pre-empted task doesn't die immediately

[Sergey Shelukhin]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57405/
---

(Updated March 10, 2017, 12:20 a.m.)


Review request for hive and Siddharth Seth.


Repository: hive-git


Description
---

see jira


Diffs (updated)
-

  
llap-server/src/java/org/apache/hadoop/hive/llap/daemon/impl/TaskExecutorService.java
 c1f6c96 
  
llap-server/src/java/org/apache/hadoop/hive/llap/daemon/impl/TaskRunnerCallable.java
 18f0db9 
  
llap-server/src/test/org/apache/hadoop/hive/llap/daemon/impl/TestTaskExecutorService.java
 bf7d1d8 


Diff: https://reviews.apache.org/r/57405/diff/4/

Changes: https://reviews.apache.org/r/57405/diff/3-4/


Testing
---


Thanks,

Sergey Shelukhin

[jira] [Created] (HIVE-16164) Provide mechanism for passing HMS notification ID between transactional and non-transactional listeners.

[JIRA]

Sergio Peña created HIVE-16164:
--

 Summary: Provide mechanism for passing HMS notification ID between 
transactional and non-transactional listeners.
 Key: HIVE-16164
 URL: https://issues.apache.org/jira/browse/HIVE-16164
 Project: Hive
  Issue Type: Improvement
  Components: Metastore
Reporter: Sergio Peña
Assignee: Sergio Peña


The HMS DB notification listener currently stores an event ID on the HMS 
backend DB so that external applications (such as backup apps) can request 
incremental notifications based on the last event ID requested.

The HMS DB notification and backup applications are asynchronous. However, 
there are sometimes that applications may be required to be in sync with the 
latest HMS event in order to process an action. These applications will provide 
a listener implementation that is called by the HMS after an HMS transaction 
happened.

The problem is that the listener running after the transaction (or during the 
non-transactional context) may need the DB event ID in order to sync all events 
happened previous to that event ID, but this ID is never passed to the 
non-transactional listeners.

We can pass this event information through the EnvironmentContext found on each 
ListenerEvent implementations (such as CreateTableEvent), and send the 
EnvironmentContext to the non-transactional listeners to get the event ID.

The DbNotificactionListener already knows the event ID after calling the 
ObjectStore.addNotificationEvent(). We just need to set this event ID to the 
EnvironmentContext from each of the event notifications and make sure that this 
EnvironmentContext is sent to the non-transactional listeners.

Here's the code example when creating a table on {{create_table_core}}:

{noformat}
 ms.createTable(tbl);

  if (transactionalListeners.size() > 0) {
CreateTableEvent createTableEvent = new CreateTableEvent(tbl, true, this);
createTableEvent.setEnvironmentContext(envContext);
for (MetaStoreEventListener transactionalListener : transactionalListeners) 
{
  transactionalListener.onCreateTable(createTableEvent); // <- Here 
the notification ID is generated
}
  }

  success = ms.commitTransaction();
} finally {
  if (!success) {
ms.rollbackTransaction();
if (madeDir) {
  wh.deleteDir(tblPath, true);
}
  }
  for (MetaStoreEventListener listener : listeners) {
CreateTableEvent createTableEvent =
new CreateTableEvent(tbl, success, this);
createTableEvent.setEnvironmentContext(envContext);
listener.onCreateTable(createTableEvent);// <- Here 
we would like to consume notification ID
  }
{noformat}

We could use a specific key name that will be used on the EnvironmentContext, 
such as DB_NOTIFICATION_EVENT_ID.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16163) Remove unnecessary parentheses in HiveParser

[Pengcheng Xiong (JIRA)]

Pengcheng Xiong created HIVE-16163:
--

 Summary: Remove unnecessary parentheses in HiveParser
 Key: HIVE-16163
 URL: https://issues.apache.org/jira/browse/HIVE-16163
 Project: Hive
  Issue Type: Bug
Reporter: Pengcheng Xiong


in HiveParser.g

L2145:
{code}
columnParenthesesList
@init { pushMsg("column parentheses list", state); }
@after { popMsg(state); }
: LPAREN columnNameList RPAREN
;
{code}

should be changed to 
{code}
columnParenthesesList
@init { pushMsg("column parentheses list", state); }
@after { popMsg(state); }
: LPAREN! columnNameList RPAREN!
;
{code}

However, we also need to refactor our code. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16162) Pass hiveconf variables to ptest master and from ptest master to ptest executor

[Sahil Takiar (JIRA)]

Sahil Takiar created HIVE-16162:
---

 Summary: Pass hiveconf variables to ptest master and from ptest 
master to ptest executor
 Key: HIVE-16162
 URL: https://issues.apache.org/jira/browse/HIVE-16162
 Project: Hive
  Issue Type: Bug
Reporter: Sahil Takiar
Assignee: Sahil Takiar


There should be a way to pass hiveconf variables from the command line to the 
hive ptest master. The ptest master should then be able to pass the hiveconf 
variables from the master to each executor. This will allow the Jenkins job 
that launches ptest to pass hiveconf variables to each executor in a 
configurable way.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16161) Disable "packaging.minimizeJar" for JDBC build

[Tao Li (JIRA)]

Tao Li created HIVE-16161:
-

 Summary: Disable "packaging.minimizeJar" for JDBC build
 Key: HIVE-16161
 URL: https://issues.apache.org/jira/browse/HIVE-16161
 Project: Hive
  Issue Type: Bug
Reporter: Tao Li
Assignee: Tao Li
Priority: Critical






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Need to fix JPam issue mentioned in Hive blog

[Richard Ding]

PAM authentication is an important feature available since Hive 0.13. But
Hive blog

gives
the following warnings:

*JPAM  library that is used to provide the
> PAM authentication mode can cause HiveServer2 to go down if a user's
> password has expired. This happens because of segfault/core dumps from
> native code invoked by JPAM. Some users have also reported crashes during
> logins in other cases as well. Use of LDAP or KERBEROS is recommended.*


​JPAM also requires user to install a native library. ​Furthermore, JPAM
library seems not to have been updated since 2007.

My questions are

   1. Is the above warning still valid on newer OS? Is Hive PAM
   authentication production ready?
   2. Other projects (e.g. Ambari/Ranger/Knox) use a newer library libpam4j
   which doesn't require installation of native library. Can Hive switch to
   use libpam4j instead of JPAM?

Thanks,
Richard

Review Request 57485: HIVE-16151 BytesBytesHashTable allocates large arrays

[Sergey Shelukhin]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57485/
---

Review request for hive and Matt McCline.


Repository: hive-git


Description
---

see jira


Diffs
-

  
ql/src/java/org/apache/hadoop/hive/ql/exec/persistence/BytesBytesMultiHashMap.java
 04e24bd 


Diff: https://reviews.apache.org/r/57485/diff/1/


Testing
---


Thanks,

Sergey Shelukhin

[jira] [Created] (HIVE-16160) OutOfMemoryError: GC overhead limit exceeded on Hs2

[Kavan Suresh (JIRA)]

Kavan Suresh created HIVE-16160:
---

 Summary: OutOfMemoryError: GC overhead limit exceeded on Hs2 
 Key: HIVE-16160
 URL: https://issues.apache.org/jira/browse/HIVE-16160
 Project: Hive
  Issue Type: Bug
  Components: HiveServer2
Reporter: Kavan Suresh
Priority: Critical


Hs2 process killed by OOM:
{code:java}
 ERROR [HiveServer2-Handler-Pool: Thread-1361771]: metastore.RetryingHMSHandler 
(RetryingHMSHandler.java:invokeInternal(203)) - java.lang.OutOfMemoryError: GC 
overhead limit exceeded
at java.lang.String.toLowerCase(String.java:2647)
at 
org.datanucleus.Configuration.getInternalNameForProperty(Configuration.java:188)
at 
org.datanucleus.ExecutionContextImpl.getProperty(ExecutionContextImpl.java:1012)
at 
org.datanucleus.state.AbstractStateManager.updateLevel2CacheForFields(AbstractStateManager.java:979)
at 
org.datanucleus.state.AbstractStateManager.loadFieldsInFetchPlan(AbstractStateManager.java:1097)
at 
org.datanucleus.ExecutionContextImpl.performDetachAllOnTxnEndPreparation(ExecutionContextImpl.java:4544)
at 
org.datanucleus.ExecutionContextImpl.preCommit(ExecutionContextImpl.java:4199)
at 
org.datanucleus.ExecutionContextImpl.transactionPreCommit(ExecutionContextImpl.java:770)
at 
org.datanucleus.TransactionImpl.internalPreCommit(TransactionImpl.java:385)
at org.datanucleus.TransactionImpl.commit(TransactionImpl.java:275)
at 
org.datanucleus.api.jdo.JDOTransaction.commit(JDOTransaction.java:107)
at 
org.apache.hadoop.hive.metastore.ObjectStore.commitTransaction(ObjectStore.java:570)
at 
org.apache.hadoop.hive.metastore.ObjectStore.getTable(ObjectStore.java:1033)
at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.hadoop.hive.metastore.RawStoreProxy.invoke(RawStoreProxy.java:103)
at com.sun.proxy.$Proxy7.getTable(Unknown Source)
at 
org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table_core(HiveMetaStore.java:1915)
at 
org.apache.hadoop.hive.metastore.HiveMetaStore$HMSHandler.get_table(HiveMetaStore.java:1887)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.hadoop.hive.metastore.RetryingHMSHandler.invokeInternal(RetryingHMSHandler.java:147)
at 
org.apache.hadoop.hive.metastore.RetryingHMSHandler.invoke(RetryingHMSHandler.java:105)
at com.sun.proxy.$Proxy12.get_table(Unknown Source)
at 
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.getTable(HiveMetaStoreClient.java:1271)
at 
org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient.getTable(SessionHiveMetaStoreClient.java:131)
at sun.reflect.GeneratedMethodAccessor37.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.hadoop.hive.metastore.RetryingMetaStoreClient.invoke(RetryingMetaStoreClient.java:178)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Green unit test results

[Ashutosh Chauhan]

I went through all the builds of last 24 hours and though there are couple
of green runs, we still have quite a bit of flakiness in our tests. Most of
that is captured via jiras on :
https://issues.apache.org/jira/browse/HIVE-15058 Till we have that
flakiness I am not sure if we can enforce no commit on test failures
policy. Once flakiness is straightened out then this discussion will become
moot anyways.
Towards that I think this flaky detector job is a step in right direction.


On Thu, Mar 9, 2017 at 11:38 AM, Sergio Pena 
wrote:

> - Probably avoiding committing a patch if a flaky test is shown on the test
> results?
> - Should we add a jenkins job that checks for flaky tests like the hbase
> project did?
> https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/
>
> On Thu, Mar 9, 2017 at 10:21 AM, Ashutosh Chauhan 
> wrote:
>
> > Great news! Thanks to everyone who contributed in getting our tests and
> > test infra sorted out.
> > We would definitely want to keep the status either green or blue
> definitely
> > not red :) All our previous efforts in keeping builds green didn't bear
> > fruit.
> > So, I think we need to make some changes here.
> >
> > Any ideas what we can do to ensure green builds going forward?
> >
> > Thanks,
> > Ashutosh
> >
> > On Thu, Mar 9, 2017 at 8:07 AM, Sergio Pena 
> > wrote:
> >
> > > It's actually blue Peter :).
> > >
> > > But good job, I see that the console output is:
> > >
> > > {color:red}ERROR:{color} -1 due to no test(s) being added or modified.
> > >
> > > {color:green}SUCCESS:{color} +1 due to 10336 tests passed
> > >
> > >
> > > On Thu, Mar 9, 2017 at 8:12 AM, Peter Vary  wrote:
> > >
> > > > Hi,
> > > >
> > > > Congratulations for everyone who have helped taking care of the unit
> > test
> > > > failures!
> > > > I have got my first green run! :)
> > > >
> > > > If any of you interested in:
> > > > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/
> <
> > > > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/>
> > :)
> > > >
> > > > Great day, and again thanks everyone!
> > > >
> > > > Peter
> > >
> >
>

Re: Backward incompatible changes

[Sergio Pena]

Hey Ashutosh, thanks for soliciting feedback on this.

I like the idea you're proposing; maintaining compatibility and at the
same time adding newer features to
Hive consumes a lot of development time and effort.

However, I think some users and companies have just started to use Hive 2.x
branch as their main major upgrade on Hive
(possible due to waiting for stabilization and testing upgrades), but
cutting this major branch that just has 1 year of life
might make us look like we will forget about the quality of Hive 2.x as we
did with branch-1.

Hive 1.x latest version was 1.2, and its development stopped because new
features on Hive 2.x
Hive 2.x latest version is 2.1, and we want to create Hive 3.x because of
newer features and incompatibilities.
Will Hive 3.x have the same future after 3.1 is released?

What I'm also concerned is about these three things:

   - *Branch-2 quality commitment*.
   How will we keep the community motivated on fixing both master and
   branch-2?
   - *Harder cherry-picks between master and branch-2*.
   Because master will be incompatible by nature, then cherry-picks to
   branch-2 will be harder.
   - *Removal of MR2 on the master branch*.
   This was marked as deprecated just last year, but MR2 is still an engine
   that is used by several users.

I accept that the end of life of major versions will come at some point,
and these concerns will expire,
but Hive 2.x is kind of young, isn't it?

Should we try to stabilize the Hive 2.x line first, and have a few more
releases before starting to work on Hive 3.0?
Should we add more test coverage to Hive jenkins jobs to validate Hive 2.x
quality?
Should we agree on a date about when we should drop community support on
Hive versions to let users know about this?

Again, I like your proposal, but I'm afraid that users who just upgraded to
2.x won't have any more features and improvements
because they will be developed on 3.0.

- Sergio



On Mon, Mar 6, 2017 at 1:24 PM, Ashutosh Chauhan  wrote:

> The way it helps shedding debt  is because dev can now do refactoring
> without fear of breaking some rarely used features. The way that helps for
> adding feature faster is since codebase is lean and easier to reason about
> its much easier to add new features.
>
> More importantly though, it also helps users because we are setting the
> expectation from dev community. They can expect that future releases of 2.x
> to be backward compatible. At the same time whenever they decide to upgrade
> they only need to test their application once against 3.x as oppose to
> continuous breakage of one form or another if we continue to make
> incompatible changes in master without branching for 2.x
>
> Thanks,
> Ashutosh
>
> On Sat, Mar 4, 2017 at 10:19 AM, Edward Capriolo 
> wrote:
>
> > Also i dont follow how we remove
> >
> > On Saturday, March 4, 2017, Edward Capriolo 
> wrote:
> >
> > >
> > >
> > > On Fri, Mar 3, 2017 at 8:46 PM, Thejas Nair  > > > wrote:
> > >
> > >> +1
> > >> There are some features that are incomplete and what I would not
> > recommend
> > >> for any real production use.The 'legacy authorization mode' is a great
> > >> example of that -
> > >> https://cwiki.apache.org/confluence/display/Hive/Hive+Defaul
> > >> t+Authorization+-+Legacy+Mode
> > >> . It is inherently insecure mode that nobody should be using.
> > >>
> > >> There is also potential to cleanup of the thrift api. However, there
> are
> > >> many users of this api, we would need to go the deprecation then
> remove
> > >> after couple of releases route or so for that.
> > >>
> > >> I am sure there are many other candidates. We will have to evaluate
> each
> > >> of
> > >> those features on the risk/benefit of keeping them and arriving at a
> > >> decision.
> > >>
> > >> Also, +1 on getting a 2.2 release out before we branch.
> > >>
> > >>
> > >>
> > >> On Fri, Mar 3, 2017 at 1:50 PM, Ashutosh Chauhan <
> hashut...@apache.org
> > >> >
> > >> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > Hive project has come a long way. With wide-spread adoption also
> comes
> > >> > expectations. Expectation of being backward compatible and not
> > breaking
> > >> > things. However that doesn't come free of cost and results in lot of
> > >> legacy
> > >> > code which can't be refactored without fear of breaking things. As a
> > >> result
> > >> > project has accumulated lot of debt over time. At the same time
> there
> > >> are
> > >> > also lot of features which have seen little uptake. We may want to
> > drop
> > >> > some of those.
> > >> >
> > >> > In order to move forward and shed that debt we may need a major
> > version
> > >> > release which allows us to make backward incompatible changes and
> drop
> > >> > rarely used features. At the same time there are lots of users 

Re: Green unit test results

[Sergio Pena]

- Probably avoiding committing a patch if a flaky test is shown on the test
results?
- Should we add a jenkins job that checks for flaky tests like the hbase
project did?
https://builds.apache.org/view/H-L/view/HBase/job/HBase-Find-Flaky-Tests/

On Thu, Mar 9, 2017 at 10:21 AM, Ashutosh Chauhan 
wrote:

> Great news! Thanks to everyone who contributed in getting our tests and
> test infra sorted out.
> We would definitely want to keep the status either green or blue definitely
> not red :) All our previous efforts in keeping builds green didn't bear
> fruit.
> So, I think we need to make some changes here.
>
> Any ideas what we can do to ensure green builds going forward?
>
> Thanks,
> Ashutosh
>
> On Thu, Mar 9, 2017 at 8:07 AM, Sergio Pena 
> wrote:
>
> > It's actually blue Peter :).
> >
> > But good job, I see that the console output is:
> >
> > {color:red}ERROR:{color} -1 due to no test(s) being added or modified.
> >
> > {color:green}SUCCESS:{color} +1 due to 10336 tests passed
> >
> >
> > On Thu, Mar 9, 2017 at 8:12 AM, Peter Vary  wrote:
> >
> > > Hi,
> > >
> > > Congratulations for everyone who have helped taking care of the unit
> test
> > > failures!
> > > I have got my first green run! :)
> > >
> > > If any of you interested in:
> > > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/ <
> > > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/>
> :)
> > >
> > > Great day, and again thanks everyone!
> > >
> > > Peter
> >
>

[jira] [Created] (HIVE-16159) Flaky Test: TestOperationLoggingLayout.testSwitchLogLayout

[Ashutosh Chauhan (JIRA)]

Ashutosh Chauhan created HIVE-16159:
---

 Summary: Flaky Test: TestOperationLoggingLayout.testSwitchLogLayout
 Key: HIVE-16159
 URL: https://issues.apache.org/jira/browse/HIVE-16159
 Project: Hive
  Issue Type: Sub-task
  Components: Logging, Test
Reporter: Ashutosh Chauhan






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16158) Correct mistake in documentation for ALTER TABLE … ADD/REPLACE COLUMNS CASCADE

[Illya Yalovyy (JIRA)]

Illya Yalovyy created HIVE-16158:


 Summary: Correct mistake in documentation for ALTER TABLE … 
ADD/REPLACE COLUMNS CASCADE
 Key: HIVE-16158
 URL: https://issues.apache.org/jira/browse/HIVE-16158
 Project: Hive
  Issue Type: Bug
  Components: Documentation
Affects Versions: 1.0.0
Reporter: Illya Yalovyy


Current documentation says that key word CASCADE was introduced in Hive 0.15 
release. That information is incorrect and confuses users. The feature was 
actually released in Hive 1.1.0. (HIVE-8839) 

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Add/ReplaceColumns



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16157) SerDe for XLS File Format

[BELUGA BEHR (JIRA)]

BELUGA BEHR created HIVE-16157:
--

 Summary: SerDe for XLS File Format
 Key: HIVE-16157
 URL: https://issues.apache.org/jira/browse/HIVE-16157
 Project: Hive
  Issue Type: New Feature
Reporter: BELUGA BEHR


Please implement Hive SerDe for reading and writing XLS file format.

https://en.wikipedia.org/wiki/Microsoft_Excel#File_formats



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16156) FileSinkOperator should delete existing output target when renaming

[Xuefu Zhang (JIRA)]

Xuefu Zhang created HIVE-16156:
--

 Summary: FileSinkOperator should delete existing output target 
when renaming
 Key: HIVE-16156
 URL: https://issues.apache.org/jira/browse/HIVE-16156
 Project: Hive
  Issue Type: Bug
  Components: Operators
Affects Versions: 1.1.0
Reporter: Xuefu Zhang
Assignee: Xuefu Zhang


If a task get killed (for whatever a reason) after it completes the renaming 
the temp output to final output during commit, subsequent task attempts will 
fail when renaming because of the existence of the target output. This can 
happen, however rarely.

Hive should check the existence of the target output and delete it before 
renaming.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Green unit test results

[Ashutosh Chauhan]

Great news! Thanks to everyone who contributed in getting our tests and
test infra sorted out.
We would definitely want to keep the status either green or blue definitely
not red :) All our previous efforts in keeping builds green didn't bear
fruit.
So, I think we need to make some changes here.

Any ideas what we can do to ensure green builds going forward?

Thanks,
Ashutosh

On Thu, Mar 9, 2017 at 8:07 AM, Sergio Pena 
wrote:

> It's actually blue Peter :).
>
> But good job, I see that the console output is:
>
> {color:red}ERROR:{color} -1 due to no test(s) being added or modified.
>
> {color:green}SUCCESS:{color} +1 due to 10336 tests passed
>
>
> On Thu, Mar 9, 2017 at 8:12 AM, Peter Vary  wrote:
>
> > Hi,
> >
> > Congratulations for everyone who have helped taking care of the unit test
> > failures!
> > I have got my first green run! :)
> >
> > If any of you interested in:
> > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/ <
> > https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/> :)
> >
> > Great day, and again thanks everyone!
> >
> > Peter
>

Re: Green unit test results

[Sergio Pena]

It's actually blue Peter :).

But good job, I see that the console output is:

{color:red}ERROR:{color} -1 due to no test(s) being added or modified.

{color:green}SUCCESS:{color} +1 due to 10336 tests passed


On Thu, Mar 9, 2017 at 8:12 AM, Peter Vary  wrote:

> Hi,
>
> Congratulations for everyone who have helped taking care of the unit test
> failures!
> I have got my first green run! :)
>
> If any of you interested in:
> https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/ <
> https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/> :)
>
> Great day, and again thanks everyone!
>
> Peter

Green unit test results

[Peter Vary]

Hi,

Congratulations for everyone who have helped taking care of the unit test 
failures!
I have got my first green run! :)

If any of you interested in:
https://builds.apache.org/job/PreCommit-HIVE-Build/4049/testReport/ 
 :)

Great day, and again thanks everyone!

Peter

[jira] [Created] (HIVE-16155) No need for ConditionalTask if no conditional map join is created

[Rui Li (JIRA)]

Rui Li created HIVE-16155:
-

 Summary: No need for ConditionalTask if no conditional map join is 
created
 Key: HIVE-16155
 URL: https://issues.apache.org/jira/browse/HIVE-16155
 Project: Hive
  Issue Type: Bug
Reporter: Rui Li
Assignee: Rui Li
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16154) Determine when dynamic runtime filtering should be disabled

[Jason Dere (JIRA)]

Jason Dere created HIVE-16154:
-

 Summary: Determine when dynamic runtime filtering should be 
disabled
 Key: HIVE-16154
 URL: https://issues.apache.org/jira/browse/HIVE-16154
 Project: Hive
  Issue Type: Bug
  Components: Query Planning
Reporter: Jason Dere
Assignee: Jason Dere


Currently dynamic min/max/bloom optimization is always enabled. However there 
are times where it may not be beneficial, such as if the semijoin has a PK-FK 
relation and there are no filters on the semijoin table. Try to devise a way to 
do a cost/benefit calculation to see if there is enough benefit to adding the 
runtime filter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Review Request 57343: HIVE-16127 Separate database initialization from actual query run in TestBeeLineDriver

[Peter Vary]

> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > Hello Peter!
> > 
> > It's great to see that the qfile has a whole representative class now and 
> > the client aspect is now more separated from it...it even makes reading it 
> > more easier!
> > I've found some minor issues - and added some notes here and there :)
> > 
> > cheers

Thanks for the review Zoltan! Again helpfull comments!


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hadoop/hive/cli/control/CoreBeeLineDriver.java
> > Lines 109 (patched)
> > 
> >
> > it would be great to use java.io.File (or Path or ?) api a bit 
> > more...and get rid of the many string concatenations...

Good idea, thanks.
Done.


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hadoop/hive/cli/control/CoreBeeLineDriver.java
> > Line 110 (original), 142 (patched)
> > 
> >
> > if the execution fails.. (parser error)..there is a very 
> > uncommunicative exception saying null...could you add some description to 
> > this assertion: something like 'execution failed' or something - it would 
> > be good to show the user that the test system worked as expected - but the 
> > qfile have failed.

Done. This time only with a simple message.


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hadoop/hive/cli/control/CoreBeeLineDriver.java
> > Line 121 (original), 158 (patched)
> > 
> >
> > it would be great to give some more info about the failure...not sure 
> > what info is available at this point - but I really miss the pointer to 
> > 'hive.log'...
> > (possibly follow-up)

Will check what Zsombor planned for the Qtests in HIVE-15616.
Created a followup jira, to do provide more informative error messages and test 
output: HIVE-16152


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hadoop/hive/cli/control/CoreBeeLineDriver.java
> > Lines 165 (patched)
> > 
> >
> > i think this could be done with try-with-resources

Agreed, done


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hive/beeline/qfile/QFile.java
> > Lines 43-49 (patched)
> > 
> >
> > it would be great to have a bunch of File object references 
> > here...these strings always cause troubles - here and there (possibly in a 
> > followup)

Done it here. Refactored to use File-s where possible.


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hive/beeline/qfile/QFile.java
> > Lines 100-103 (patched)
> > 
> >
> > instead of copyToDirectory...I would recommend to use the expected - I 
> > know they should be the same... (or possibly there is some hidden magic 
> > which I'm not aware of :)

The original hidden magic was about creating the resultsDirectory folder, if 
that folder or any of the parents are not exists, then 
copyFileToDirectory(..,true) created the missing directories. I do not think we 
need that here, so removed


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hive/beeline/qfile/QFile.java
> > Lines 105 (patched)
> > 
> >
> > I think it would be better to throw this execption out...the user 
> > expects it to be overwritten - if this is the only thing that fails - it 
> > may cover-up to a non-updateable file like dir and file owned by root by a 
> > mistake...

Agreed, done


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hive/beeline/qfile/QFile.java
> > Lines 266 (patched)
> > 
> >
> > I don't really see why staticfilterset is needed...and it's field - it 
> > seems to me that they are used at the same time...

I have created two groups of filters:
- One which is same for every tests
- One which is test specific

This way we have to create fewer objects when we run multiple tests.
Added comments to clarify the difference


> On March 8, 2017, 4:43 p.m., Zoltan Haindrich wrote:
> > itests/util/src/main/java/org/apache/hive/beeline/qfile/QFileBeeLineClient.java
> > Lines 70 (patched)
> > 
> >
> > i don't think this should be asserted...if you run your jvm without -ea 
> > this method is not even invoked

Re: Review Request 57343: HIVE-16127 Separate database initialization from actual query run in TestBeeLineDriver

[Peter Vary]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/57343/
---

(Updated March 9, 2017, 10:05 a.m.)


Review request for hive, Zoltan Haindrich, Naveen Gangam, Sergio Pena, Vihang 
Karajgaonkar, and Barna Zsombor Klara.


Changes
---

Addressed review comments, rebased to head


Bugs: HIVE-16127
https://issues.apache.org/jira/browse/HIVE-16127


Repository: hive-git


Description
---

Refactored the QFileClient:
- Moved to itest/util
- Separated QFile specific code parts (file path, and filtering)
- Separated BeeLineClient specific code (execution of the queries, commands)
- Created factories for QFile, and Client, so after initialization they can be 
reused during multiple tests
- Separated init script run from actual test run, so multiple tests could be 
run against a single MiniHS2 instance
- Removed unused property


Diffs (updated)
-

  beeline/src/java/org/apache/hive/beeline/util/QFileClient.java d99483e 
  itests/src/test/resources/testconfiguration.properties 2a7627a 
  
itests/util/src/main/java/org/apache/hadoop/hive/cli/control/CoreBeeLineDriver.java
 aba1fde 
  itests/util/src/main/java/org/apache/hive/beeline/qfile/QFile.java 
PRE-CREATION 
  
itests/util/src/main/java/org/apache/hive/beeline/qfile/QFileBeeLineClient.java 
PRE-CREATION 
  itests/util/src/main/java/org/apache/hive/beeline/qfile/package-info.java 
PRE-CREATION 
  ql/src/test/results/clientpositive/beeline/drop_with_concurrency.q.out 
PRE-CREATION 


Diff: https://reviews.apache.org/r/57343/diff/3/

Changes: https://reviews.apache.org/r/57343/diff/2-3/


Testing
---

Used the previosly generated test to validate that the result is not changed.
Added one more test to check the separation is done correctly.


Thanks,

Peter Vary

[jira] [Created] (HIVE-16153) Cannot run Hive 2.1.1 with Hadoop 3.0.0-alpha1

[Benjamin Steinvorth (JIRA)]

Benjamin Steinvorth created HIVE-16153:
--

 Summary: Cannot run Hive 2.1.1 with Hadoop 3.0.0-alpha1
 Key: HIVE-16153
 URL: https://issues.apache.org/jira/browse/HIVE-16153
 Project: Hive
  Issue Type: Bug
Affects Versions: 2.1.1
Reporter: Benjamin Steinvorth


2017-03-09 10:38:15,426 ERROR metastore.HiveMetaStore: Metastore Thrift Server 
threw an exception...
java.lang.IllegalArgumentException: Unrecognized Hadoop major version number: 
3.0.0-alpha1
at 
org.apache.hadoop.hive.shims.ShimLoader.getMajorVersion(ShimLoader.java:169)
at 
org.apache.hadoop.hive.shims.ShimLoader.loadShims(ShimLoader.java:136)
at 
org.apache.hadoop.hive.shims.ShimLoader.getHadoopThriftAuthBridge(ShimLoader.java:122)
at 
org.apache.hadoop.hive.metastore.HiveMetaStore.main(HiveMetaStore.java:6664)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.util.RunJar.run(RunJar.java:239)
at org.apache.hadoop.util.RunJar.main(RunJar.java:153)
Exception in thread "main" java.lang.IllegalArgumentException: Unrecognized 
Hadoop major version number: 3.0.0-alpha1
at 
org.apache.hadoop.hive.shims.ShimLoader.getMajorVersion(ShimLoader.java:169)
at 
org.apache.hadoop.hive.shims.ShimLoader.loadShims(ShimLoader.java:136)
at 
org.apache.hadoop.hive.shims.ShimLoader.getHadoopThriftAuthBridge(ShimLoader.java:122)
at 
org.apache.hadoop.hive.metastore.HiveMetaStore.main(HiveMetaStore.java:6664)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.hadoop.util.RunJar.run(RunJar.java:239)
at org.apache.hadoop.util.RunJar.main(RunJar.java:153)
2017-03-09 10:38:15,485 INFO metastore.HiveMetaStore: Shutting down hive 
metastore.
2017-03-09 10:38:15,518 INFO metastore.HiveMetaStore: SHUTDOWN_MSG:



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (HIVE-16152) TestBeeLineDriver logging improvements

[Peter Vary (JIRA)]

Peter Vary created HIVE-16152:
-

 Summary: TestBeeLineDriver logging improvements
 Key: HIVE-16152
 URL: https://issues.apache.org/jira/browse/HIVE-16152
 Project: Hive
  Issue Type: Improvement
  Components: Testing Infrastructure
Affects Versions: 2.2.0
Reporter: Peter Vary
Assignee: Peter Vary


During the review of HIVE-16127 we agreed, that it would be great to have 
improved logging and error messages during the TestBeeLineDriver run.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)