Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.albasani.net!newsfeed.freenet.ag!news2.euro.net!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.004 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'python,': 0.02; 'answering': 0.09; 'thread': 0.11; 'portion': 0.13; 'sat,': 0.15; '"cancel"': 0.16; 'heed': 0.16; 'nesting': 0.16; 'problem).': 0.16; 'programmatic': 0.16; 'subject:threads': 0.16; 'threads': 0.16; 'wrote:': 0.17; 'pieces': 0.17; 'jan': 0.18; 'solution.': 0.18; 'email addr:gmail.com>': 0.20; 'to:name:python- list@python.org': 0.20; 'trying': 0.21; 'not,': 0.21; 'assuming': 0.22; 'recognize': 0.22; '>': 0.23; 'minutes.': 0.23; 'header :In-Reply-To:1': 0.25; '(which': 0.26; 'am,': 0.27; 'question': 0.27; 'message-id:@mail.gmail.com': 0.27; 'run': 0.28; 'url:mailman': 0.29; 'skip:& 10': 0.29; 'that.': 0.30; 'query': 0.30; 'figure': 0.30; 'url:python': 0.32; 'quickly': 0.32; 'could': 0.32; 'url:listinfo': 0.32; 'cancel': 0.33; 'problem': 0.33; 'to:addr:python-list': 0.33; 'received:google.com': 0.34; 'server': 0.35; 'jason': 0.35; 'expected': 0.35; 'sometimes': 0.35; 'received:209.85': 0.35; 'url:org': 0.36; 'generation': 0.36; 'possible': 0.37; 'execute': 0.37; 'itself': 0.37; 'does': 0.37; 'received:209': 0.37; 'subject:: ': 0.38; 'to:addr:python.org': 0.39; 'takes': 0.39; 'url:mail': 0.40; 'your': 0.60; 'real': 0.61; 'respect': 0.63; '26,': 0.65; 'sounds': 0.71; '2013': 0.84 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=JzWi2Fid3HFY09RJy3Lj80nDfttaWm2HsC2DcLRJIs4=; b=qq1yDHQv8Y2bbmE2s1UbSrm6e5IxsVf27Soh40B+0+zYseWPxOoaIQzOU9ZjAJPaUE 7r50SIdDfH04Dl8ZFlOmYssd6oq4ngxXu3R7WmBUPlflX5BSvPzO7KaP07TekjpDhcyf 0WWRbfa5RWKLsuQD4NvMAFcG3kBw0Q1RZtLuMTXzH2maHbU7PeW1vWzpEYWmtBnK37xl 5PsQcajiw7xwCMYeceBV6bT5zigJDruW/jMxdUZvnoQAu+LmRvufHAdmyW1JYPwI24Dj OgpV9ysZYuzCQNjCVZQGhWp4hcXDUMcWHjnqDawSzou+e4tJ9VEK7VyKTiFD6vcUoQwE dLVQ== X-Received: by 10.182.38.65 with SMTP id e1mr7222765obk.3.1359215331114; Sat, 26 Jan 2013 07:48:51 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20130126131408.GA6300@sagitarius.getae.net> From: Matt Jones Date: Sat, 26 Jan 2013 09:48:31 -0600 Subject: Re: Cancel threads after timeout To: "python-list@python.org" Content-Type: multipart/alternative; boundary=f46d044787c5fbff0b04d432fa76 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 83 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1359215340 news.xs4all.nl 6907 [2001:888:2000:d::a6]:52477 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:37724 --f46d044787c5fbff0b04d432fa76 Content-Type: text/plain; charset=ISO-8859-1 It sounds like your real problem is with your SQL query... Is that part of this problem under your control? Can you break the query into smaller, quicker, pieces that you can run in a reasonable amount of time? If not, nesting threads might be your best programmatic solution. Heed Jason's warning though that the SQL Server my still be working even if you cancel an operation from the outside (which could compound your problem). *Matt Jones* On Sat, Jan 26, 2013 at 9:43 AM, Jason Friedman wrote: > > Sometimes it happens that a query on one of the database servers > > takes longer than expected and impedes the generation of this report > > (that's right, the queries are ran sequential). What I am trying to > > achieve is to parallelize the queries on each database server and to be > > able to cancel one of them if it takes longer than X minutes. > > Only answering a small portion of your question .... > Assuming you are able to figure out how to "cancel" a thread or > process on your side, it is possible the database itself will not > respect that. In other words, if you execute "SELECT ..." singly, > outside of Python, and type CNTL-C, does your database quickly > recognize you are no longer interested in the result set and stop its > work? > -- > http://mail.python.org/mailman/listinfo/python-list > --f46d044787c5fbff0b04d432fa76 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It sounds like your real problem is with your SQL query... =A0Is that pa= rt of this problem under your control? =A0Can you break the query into smal= ler, quicker, pieces that you can run in a=A0reasonable=A0amount of time?

If not, nesting threads might be your best=A0programmatic solution. = =A0Heed Jason's warning though that the SQL Server my still be working = even if you cancel an operation from the outside (which could compound your= problem).

Matt Jones

On Sat, Jan 26, 2013 at 9:43 AM, Jason F= riedman <jsf80238@gmail.com> wrote:
> Sometimes it happens that a query on one of the data= base servers
> takes longer than expected and impedes the generation of this report > (that's right, the queries are ran sequential). What I am trying t= o
> achieve is to parallelize the queries on each database server and to b= e
> able to cancel one of them if it takes longer than X minutes.

Only answering a small portion of your question ....
Assuming you are able to figure out how to "cancel" a thread or process on your side, it is possible the database itself will not
respect that. =A0In other words, if you execute "SELECT ..." sing= ly,
outside of Python, and type CNTL-C, does your database quickly
recognize you are no longer interested in the result set and stop its
work?
--
http://mail.python.org/mailman/listinfo/python-list

--f46d044787c5fbff0b04d432fa76--