[jira] [Commented] (HIVE-10507) Expose RetryingMetastoreClient to other external users of metastore client like Flume and Storm.
[ https://issues.apache.org/jira/browse/HIVE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520361#comment-14520361 ] Sushanth Sowmyan commented on HIVE-10507: - Although we've passed the deadline for feature inclusions, this is more a clarification, and a trivial one at that - I can make an exception for this. Please note that if you have any further jiras like this, please do check with me asap, because after tomorrow 15:01 PDT, I will be more strict in accepting patches of all sorts as we increase the severity bar for inclusion then. I've added this to https://cwiki.apache.org/confluence/display/Hive/Hive+1.2+Release+Status > Expose RetryingMetastoreClient to other external users of metastore client > like Flume and Storm. > - > > Key: HIVE-10507 > URL: https://issues.apache.org/jira/browse/HIVE-10507 > Project: Hive > Issue Type: Bug >Reporter: Hari Sankar Sivarama Subramaniyan >Assignee: Hari Sankar Sivarama Subramaniyan > Attachments: HIVE-10507.1.patch > > > HiveMetastoreClient is now being relied upon by external clients like Flume > and Storm for streaming. > When the thrift connection between MetaStoreClient and the meta store is > broken (due to intermittent network issues or restarting of metastore) the > Metastore does not handle the connection error and automatically re-establish > the connection. Currently the client process needs to be restarted to > re-establish the connection. > The request here is consider supporting the following behavior: For each API > invocation on the MetastoreClient, it should try to restablish the connection > (if needed) once. And if that does not work out then throw a specific > exception indicating the same. The client could then handle the issue by > retrying the same API after some delay. By catching the specific connection > exception, the client could decide how many times to retry before aborting. > Hive does this internally using RetryingMetastoreClient. This jira is suppose > to expose this mechanism to other users of that interface. This is useful for > users of this interface, and from metastore HA point of view. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HIVE-10507) Expose RetryingMetastoreClient to other external users of metastore client like Flume and Storm.
[ https://issues.apache.org/jira/browse/HIVE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520169#comment-14520169 ] Thejas M Nair commented on HIVE-10507: -- [~sushanth] This is a simple javadoc change, but an important change to clarify the api usage. It would be good to have this in 1.2.0. > Expose RetryingMetastoreClient to other external users of metastore client > like Flume and Storm. > - > > Key: HIVE-10507 > URL: https://issues.apache.org/jira/browse/HIVE-10507 > Project: Hive > Issue Type: Bug >Reporter: Hari Sankar Sivarama Subramaniyan >Assignee: Hari Sankar Sivarama Subramaniyan > Attachments: HIVE-10507.1.patch > > > HiveMetastoreClient is now being relied upon by external clients like Flume > and Storm for streaming. > When the thrift connection between MetaStoreClient and the meta store is > broken (due to intermittent network issues or restarting of metastore) the > Metastore does not handle the connection error and automatically re-establish > the connection. Currently the client process needs to be restarted to > re-establish the connection. > The request here is consider supporting the following behavior: For each API > invocation on the MetastoreClient, it should try to restablish the connection > (if needed) once. And if that does not work out then throw a specific > exception indicating the same. The client could then handle the issue by > retrying the same API after some delay. By catching the specific connection > exception, the client could decide how many times to retry before aborting. > Hive does this internally using RetryingMetastoreClient. This jira is suppose > to expose this mechanism to other users of that interface. This is useful for > users of this interface, and from metastore HA point of view. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HIVE-10507) Expose RetryingMetastoreClient to other external users of metastore client like Flume and Storm.
[ https://issues.apache.org/jira/browse/HIVE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14520163#comment-14520163 ] Thejas M Nair commented on HIVE-10507: -- +1 > Expose RetryingMetastoreClient to other external users of metastore client > like Flume and Storm. > - > > Key: HIVE-10507 > URL: https://issues.apache.org/jira/browse/HIVE-10507 > Project: Hive > Issue Type: Bug >Reporter: Hari Sankar Sivarama Subramaniyan >Assignee: Hari Sankar Sivarama Subramaniyan > Attachments: HIVE-10507.1.patch > > > HiveMetastoreClient is now being relied upon by external clients like Flume > and Storm for streaming. > When the thrift connection between MetaStoreClient and the meta store is > broken (due to intermittent network issues or restarting of metastore) the > Metastore does not handle the connection error and automatically re-establish > the connection. Currently the client process needs to be restarted to > re-establish the connection. > The request here is consider supporting the following behavior: For each API > invocation on the MetastoreClient, it should try to restablish the connection > (if needed) once. And if that does not work out then throw a specific > exception indicating the same. The client could then handle the issue by > retrying the same API after some delay. By catching the specific connection > exception, the client could decide how many times to retry before aborting. > Hive does this internally using RetryingMetastoreClient. This jira is suppose > to expose this mechanism to other users of that interface. This is useful for > users of this interface, and from metastore HA point of view. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HIVE-10507) Expose RetryingMetastoreClient to other external users of metastore client like Flume and Storm.
[ https://issues.apache.org/jira/browse/HIVE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14518154#comment-14518154 ] Hari Sankar Sivarama Subramaniyan commented on HIVE-10507: -- The test failures are unrelated to this change. Thanks Hari > Expose RetryingMetastoreClient to other external users of metastore client > like Flume and Storm. > - > > Key: HIVE-10507 > URL: https://issues.apache.org/jira/browse/HIVE-10507 > Project: Hive > Issue Type: Bug >Reporter: Hari Sankar Sivarama Subramaniyan >Assignee: Hari Sankar Sivarama Subramaniyan > Attachments: HIVE-10507.1.patch > > > HiveMetastoreClient is now being relied upon by external clients like Flume > and Storm for streaming. > When the thrift connection between MetaStoreClient and the meta store is > broken (due to intermittent network issues or restarting of metastore) the > Metastore does not handle the connection error and automatically re-establish > the connection. Currently the client process needs to be restarted to > re-establish the connection. > The request here is consider supporting the following behavior: For each API > invocation on the MetastoreClient, it should try to restablish the connection > (if needed) once. And if that does not work out then throw a specific > exception indicating the same. The client could then handle the issue by > retrying the same API after some delay. By catching the specific connection > exception, the client could decide how many times to retry before aborting. > Hive does this internally using RetryingMetastoreClient. This jira is suppose > to expose this mechanism to other users of that interface. This is useful for > users of this interface, and from metastore HA point of view. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HIVE-10507) Expose RetryingMetastoreClient to other external users of metastore client like Flume and Storm.
[
https://issues.apache.org/jira/browse/HIVE-10507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14517045#comment-14517045
]
Hive QA commented on HIVE-10507:
{color:red}Overall{color}: -1 at least one tests failed
Here are the results of testing the latest attachment:
https://issues.apache.org/jira/secure/attachment/12728609/HIVE-10507.1.patch
{color:red}ERROR:{color} -1 due to 14 failed/errored test(s), 8818 tests
executed
*Failed tests:*
{noformat}
TestMinimrCliDriver-bucketmapjoin6.q-constprog_partitioner.q-infer_bucket_sort_dyn_part.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-external_table_with_space_in_location_path.q-infer_bucket_sort_merge.q-auto_sortmerge_join_16.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-groupby2.q-import_exported_table.q-bucketizedhiveinputformat.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-index_bitmap3.q-stats_counter_partitioned.q-temp_table_external.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-infer_bucket_sort_map_operators.q-join1.q-bucketmapjoin7.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-infer_bucket_sort_num_buckets.q-disable_merge_for_bucketing.q-uber_reduce.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-infer_bucket_sort_reducers_power_two.q-scriptfile1.q-scriptfile1_win.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-leftsemijoin_mr.q-load_hdfs_file_with_space_in_the_name.q-root_dir_external_table.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-list_bucket_dml_10.q-bucket_num_reducers.q-bucket6.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-load_fs2.q-file_with_header_footer.q-ql_rewrite_gbtoidx_cbo_1.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-parallel_orderby.q-reduce_deduplicate.q-ql_rewrite_gbtoidx_cbo_2.q-and-1-more
- did not produce a TEST-*.xml file
TestMinimrCliDriver-ql_rewrite_gbtoidx.q-smb_mapjoin_8.q - did not produce a
TEST-*.xml file
TestMinimrCliDriver-schemeAuthority2.q-bucket4.q-input16_cc.q-and-1-more - did
not produce a TEST-*.xml file
org.apache.hive.jdbc.TestSSL.testSSLConnectionWithProperty
{noformat}
Test results:
http://ec2-174-129-184-35.compute-1.amazonaws.com/jenkins/job/PreCommit-HIVE-TRUNK-Build/3624/testReport
Console output:
http://ec2-174-129-184-35.compute-1.amazonaws.com/jenkins/job/PreCommit-HIVE-TRUNK-Build/3624/console
Test logs:
http://ec2-174-129-184-35.compute-1.amazonaws.com/logs/PreCommit-HIVE-TRUNK-Build-3624/
Messages:
{noformat}
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
Tests exited with: TestsFailedException: 14 tests failed
{noformat}
This message is automatically generated.
ATTACHMENT ID: 12728609 - PreCommit-HIVE-TRUNK-Build
> Expose RetryingMetastoreClient to other external users of metastore client
> like Flume and Storm.
> -
>
> Key: HIVE-10507
> URL: https://issues.apache.org/jira/browse/HIVE-10507
> Project: Hive
> Issue Type: Bug
>Reporter: Hari Sankar Sivarama Subramaniyan
>Assignee: Hari Sankar Sivarama Subramaniyan
> Attachments: HIVE-10507.1.patch
>
>
> HiveMetastoreClient is now being relied upon by external clients like Flume
> and Storm for streaming.
> When the thrift connection between MetaStoreClient and the meta store is
> broken (due to intermittent network issues or restarting of metastore) the
> Metastore does not handle the connection error and automatically re-establish
> the connection. Currently the client process needs to be restarted to
> re-establish the connection.
> The request here is consider supporting the following behavior: For each API
> invocation on the MetastoreClient, it should try to restablish the connection
> (if needed) once. And if that does not work out then throw a specific
> exception indicating the same. The client could then handle the issue by
> retrying the same API after some delay. By catching the specific connection
> exception, the client could decide how many times to retry before aborting.
> Hive does this internally using RetryingMetastoreClient. This jira is suppose
> to expose this mechanism to other users of that interface. This is useful for
> users of this interface, and from metastore HA point of view.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
