Return-Path: X-Original-To: archive-asf-public@eu.ponee.io Delivered-To: archive-asf-public@eu.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by mx-eu-01.ponee.io (Postfix) with ESMTP id 86F53180630 for ; Tue, 2 Jan 2018 19:12:40 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 76B15160C26; Tue, 2 Jan 2018 18:12:40 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id ADDEF160C09 for ; Tue, 2 Jan 2018 19:12:39 +0100 (CET) Received: (qmail 52183 invoked by uid 500); 2 Jan 2018 18:12:38 -0000 Mailing-List: contact user-help@impala.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@impala.apache.org Delivered-To: mailing list user@impala.apache.org Received: (qmail 52173 invoked by uid 99); 2 Jan 2018 18:12:38 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 02 Jan 2018 18:12:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 4BA6B1A000F for ; Tue, 2 Jan 2018 18:12:38 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.879 X-Spam-Level: * X-Spam-Status: No, score=1.879 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 7SmK4jhGxX-A for ; Tue, 2 Jan 2018 18:12:37 +0000 (UTC) Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id E627F5F27E for ; Tue, 2 Jan 2018 18:12:36 +0000 (UTC) Received: by mail-vk0-f51.google.com with SMTP id x64so14181120vkd.6 for ; Tue, 02 Jan 2018 10:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=GCpXKscwGwevGFfBu61j3b/3TL3F4zaM2fwJruCZk0E=; b=L9CHTdEN5+z7ExFLrbaYbHER3WDVJWhGQw3/bqN+qDsIrxkZHrCVDQ9Yc9vW5VIVn0 43jWY5SdM4v5u9b4TH7jFk3hEyM8W7x/Dk3OF0tM9JNpbcHDv2Ypk5lqj9OiuRHzxpyD xL9MKnwsRsoVMxt6Yu3PvcGwbi3DS8RRGqhe5O8uQat8IpWPUqDxFNv/aoJlE7RsVMcK wsdNkocYUFMMOSNo8BqpuZKYTjm63fXMNHcZbC57u6WwPXn/SFWAhtcBZWktCNmz4P7q ZUwPAle5n2qOQ4IIFuLnvfP2ZP6NIjloegxgm/V/5cLIghe8L7DcWkjcuuAGnwL5ZIcp 94Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=GCpXKscwGwevGFfBu61j3b/3TL3F4zaM2fwJruCZk0E=; b=oEFuXNz8q8RYAyS8e2rr09oCBan1dHAqTAIkVdXoDh3bZNJbZ3zfD2CHbqD3R+/NeY PoXYuvnqiNLECFk4GUTepiiaIM+3M30iv3o3PbK0JB9u7KR4p8KxqpoxvI8W90529qoV bEYQ8X2dyt2SGCcCWSPn5+abgd9aObTHs4FQelcHD+kQpybRzkxVqlt059e95SP0Ztxu zgO1k2cukXwbJOnw3GtfwjDoMYeGu3ndAD9Q0p8jJCudAH8wR/nVr+ZGSJ75J6P6uxNa vWtKXYABbUurtFV+PbXMTtK3zH4d4WgJ+DeTIpTMbYIqkA6/bTnCS5dtQaDYlVjJadt5 1VGA== X-Gm-Message-State: AKGB3mLtFY+SsU5aZGQp/8SIzThNiBGBclXix+J/I170kJ7w7+f6NRPs ZHNDwvaPZSDCQt4SMRjiEz9vFmuExdCquaNPoVDOSg== X-Google-Smtp-Source: ACJfBotvfoMxxilqqbDjCjby5t78RpFLCw+582LIB87lZK6JoPdT0vk5jAKUQ99pniNd3vd4rvM9HLPTTdzL4hM66GM= X-Received: by 10.31.3.201 with SMTP id f70mr43891306vki.84.1514916756266; Tue, 02 Jan 2018 10:12:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.72.175 with HTTP; Tue, 2 Jan 2018 10:12:35 -0800 (PST) From: Oleksandr Baliev Date: Tue, 2 Jan 2018 19:12:35 +0100 Message-ID: Subject: Impala query (via JDBC) timeout To: user@impala.apache.org Content-Type: multipart/alternative; boundary="001a11428f0a1f25a30561cf0b61" archived-at: Tue, 02 Jan 2018 18:12:40 -0000 --001a11428f0a1f25a30561cf0b61 Content-Type: text/plain; charset="UTF-8" Hello, I'm using impala in conjunction with CDH 5.10.1 and want to have timeouts for long running queries. What I've found is: 1. Try to QUERY_TIMEOUT_S to close idle queries, as I understand when client is closed and don't consume data. 2. for jdbc driver (version 2.5.37 or 4.1) there is setQueryTimeout(int). which should set xlient side timeout as I understand ( https://www.cloudera.com/documentation/other/connectors/impala-jdbc/latest/Cloudera-JDBC-Driver-for-Impala-Install-Guide.pdf) . It works, but: 2.1 when timeout occurs the query is in "waiting to be closed", even if close Statement (for Java). And only if close Connection this query will we removed from "in_flight_queries". 2.2 not sure, haven't checked fully, but seems this timeout can happen only when query on earlier stage of executing, maybe when it's executing it's okay, but when data is transmitting it cannot be timeout-ed. 3. Write some cron script to verify such queries via impalad /queries?json and try to close them to do not consume resources. To be honest I would prefer for now to have some external script which could tell if there are any of such queries and react manually/automatically + introduce some connection reconnect if there were any of such timeouted queries on application level. Also maybe there are some another situations when queries are nor closing, so I don't know maybe just reconnect every 20 minutes :D But this solutions are just workaround and I don't really can rely on them since they look a bit fragile. So the question: is there any good way for the queries via jdbc to be gracefully closed by given timeout ? Will be very thankful for any hints :) Sasha --001a11428f0a1f25a30561cf0b61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,=C2=A0

I'm using impala in co= njunction with CDH 5.10.1 and want to have timeouts for long running querie= s. What I've found is:
1. Try to QUERY_TIMEOUT_S to close idl= e queries, as I understand when client is closed and don't consume data= .=C2=A0
2. for jdbc driver (version 2.5.37 or 4.1) there is setQu= eryTimeout(int). which should set xlient side timeout as I understand (https://www.cloud= era.com/documentation/other/connectors/impala-jdbc/latest/Cloudera-JDBC-Dri= ver-for-Impala-Install-Guide.pdf)=C2=A0 . It works, but:
2.1 = when timeout occurs the query is in "waiting to be closed", even = if close Statement (for Java). And only if close Connection this query will= we removed from "in_flight_queries".=C2=A0
2.2 not sure, haven't= checked fully, but seems this timeout can happen only when query on earlie= r stage of executing, maybe when it's executing it's okay, but when= data is transmitting it cannot be timeout-ed.=C2=A0
3. Write som= e cron script to verify such queries via impalad /queries?json and try to c= lose them to do not consume resources.

To be hones= t I would prefer for now to have some external script which could tell if t= here are any of such queries and react manually/automatically + introduce s= ome connection reconnect if there were any of such timeouted queries on app= lication level. Also maybe there are some another situations when queries a= re nor closing, so I don't know maybe just reconnect every 20 minutes := D But this solutions are just workaround and I don't really can rely on= them since they look a bit fragile.

So the questi= on: is there any good way for the queries via jdbc to be gracefully closed = by given timeout ?=C2=A0

Will be very thankful for= any hints :)=C2=A0
Sasha


--001a11428f0a1f25a30561cf0b61--