hive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Jenkins Server <jenk...@builds.apache.org>
Subject Hive-trunk-h0.21 - Build # 1392 - Still Failing
Date Tue, 24 Apr 2012 06:51:30 GMT
Changes for Build #1391
[cws] HIVE-2928. Support for Oracle-backed Hive-Metastore (longvarchar to clob in package.jdo)
(Mithun Radhakrishnan and Andrew Bayer via cws)

[cws] HIVE-2646. Hive Ivy dependencies on Hadoop should depend on jars directly, not tarballs
(Andrew Bayer and Thomas Weise)

[hashutosh] HIVE-2970: several jars in hive tar generated are not required (Thejas Nair via
Ashutosh Chauhan)


Changes for Build #1392
[cws] HIVE-2803 [jira] utc_from_timestamp and utc_to_timestamp returns incorrect
results.
(Kiyotaka Suzuki via Carl Steinbach)

Summary:
https://issues.apache.org/jira/browse/HIVE-2803

HIVE-2803 utc_from_timestamp and utc_to_timestamp returns incorrect results.

It changed so that applyOffset() return a new instance.

How to reproduce:


$ echo "2011-12-25 09:00:00.123456" > /tmp/data5.txt
hive> create table ts1(t1 timestamp);
hive> load data local inpath '/tmp/data5.txt' overwrite into table ts1;
hive> select t1, from_utc_timestamp(t1, 'JST'), from_utc_timestamp(t1, 'JST')
from ts1 limit 1;



The following result is expected:

 2011-12-25 09:00:00.123456      2011-12-25 18:00:00.123456      2011-12-25
18:00:00.123456


However, the above query return incorrect result like this:

 2011-12-26 03:00:00.492456      2011-12-26 03:00:00.492456      2011-12-26
03:00:00.492456



This is because GenericUDFFromUtcTimestamp.applyOffset() does setTime()
improperly.
On evaluating query, timestamp argument always returns the same instance.
GenericUDFFromUtcTimestamp.applyOffset() does setTime() on the instance.
That means it adds all offsets in the query.

Test Plan: EMPTY

Reviewers: JIRA

Differential Revision: https://reviews.facebook.net/D1959

[namit] HIVE-2703 ResultSetMetaData.getColumnType() always returns VARCHAR(string) for partition
columns
irrespective of partition column type (tamtam180 via namit)

[hashutosh] HIVE-2883 [jira] Metastore client doesnt close connection properly

Summary:
https://issues.apache.org/jira/browse/HIVE-2883

Here is the patch which gets rid of this problem as per my hypothesis. I also
tested it and the above noted stack trace doesnt occur anymore.

While closing connection, it always fail with following trace. Seemingly, it
doesnt have any harmful effects.

12/03/20 10:55:02 ERROR hive.metastore: Unable to shutdown local metastore
client
org.apache.thrift.transport.TTransportException: Cannot write to null
outputStream
	at
org.apache.thrift.transport.TIOStreamTransport.write(TIOStreamTransport.java:142)
	at
org.apache.thrift.protocol.TBinaryProtocol.writeI32(TBinaryProtocol.java:163)
	at
org.apache.thrift.protocol.TBinaryProtocol.writeMessageBegin(TBinaryProtocol.java:91)
	at org.apache.thrift.TServiceClient.sendBase(TServiceClient.java:62)
	at
com.facebook.fb303.FacebookService$Client.send_shutdown(FacebookService.java:421)
	at com.facebook.fb303.FacebookService$Client.shutdown(FacebookService.java:415)
	at
org.apache.hadoop.hive.metastore.HiveMetaStoreClient.close(HiveMetaStoreClient.java:310)

Test Plan: EMPTY

Reviewers: JIRA, cwsteinbach

Reviewed By: cwsteinbach

Differential Revision: https://reviews.facebook.net/D2613




All tests passed

The Apache Jenkins build system has built Hive-trunk-h0.21 (build #1392)

Status: Still Failing

Check console output at https://builds.apache.org/job/Hive-trunk-h0.21/1392/ to view the results.
Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message