Path: csiph.com!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.erje.net!eu.feeder.erje.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.011 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'python,': 0.02; 'answering': 0.09; 'cc:addr:python-list': 0.10; 'thread': 0.11; 'assume': 0.11; 'portion': 0.13; 'sat,': 0.15; '"cancel"': 0.16; 'heed': 0.16; 'nesting': 0.16; 'problem).': 0.16; 'programmatic': 0.16; 'query,': 0.16; 'refactoring': 0.16; 'subject:threads': 0.16; 'threads': 0.16; 'wrote:': 0.17; 'pieces': 0.17; 'jan': 0.18; 'solution.': 0.18; 'trying': 0.21; 'not,': 0.21; 'assuming': 0.22; 'recognize': 0.22; 'cc:2**0': 0.23; 'minutes.': 0.23; 'cc:addr:python.org': 0.25; 'header:In-Reply-To:1': 0.25; 'header :User-Agent:1': 0.26; '(which': 0.26; 'am,': 0.27; 'question': 0.27; 'run': 0.28; 'url:mailman': 0.29; "i'm": 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; 'getting': 0.33; 'cancel': 0.33; 'problem': 0.33; 'server': 0.35; 'jason': 0.35; 'expected': 0.35; 'sometimes': 0.35; 'there': 0.35; 'but': 0.36; 'url:org': 0.36; 'generation': 0.36; 'thank': 0.36; 'charset :us-ascii': 0.36; 'possible': 0.37; 'execute': 0.37; 'itself': 0.37; 'does': 0.37; 'subject:: ': 0.38; 'step': 0.39; 'takes': 0.39; 'received:192': 0.39; 'notice': 0.39; 'received:192.168': 0.40; 'url:mail': 0.40; 'your': 0.60; 'content- disposition:inline': 0.60; 'you.': 0.61; 'real': 0.61; 'first': 0.61; 'respect': 0.63; 'more': 0.63; 'management': 0.65; '26,': 0.65; 'risk': 0.66; 'receive': 0.71; 'sounds': 0.71; '2013': 0.84; 'received:72.249': 0.84; 'received:83.103': 0.84 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=nerdshack.com; b=Jd3XDgBQDvDaHVnuUuga6tnxkEYBH2gD8mX8dCW6kl+3U9z0WSOUAZG+fCYKxBm8h0tngZ38f0Ou+akyEVMMyIqTbLFVr7HAnBNBg5hRVbBtMBCY1EIGeQRrOt3DQubmyd852odQZfQn+uAiIAF9Hrj/psIiRHy4PmFhOA1aHMs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent; Date: Sun, 27 Jan 2013 11:51:49 +0200 From: hyperboreean To: Matt Jones Subject: Re: Cancel threads after timeout References: <20130126131408.GA6300@sagitarius.getae.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "python-list@python.org" 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: 43 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1359280318 news.xs4all.nl 6847 [2001:888:2000:d::a6]:50755 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:37770 On 01/26, Matt Jones wrote: The SQL part is not under control and getting it there requires more development time than the management is willing to allocate. So this would be a first step before refactoring that part. I'm aware that the database might not notice that I don't want to receive the result of the query, but I'm willing to assume that risk for now. Thank you. > 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 > > > -- > http://mail.python.org/mailman/listinfo/python-list