Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5E6C618C41 for ; Sat, 21 Nov 2015 08:41:30 +0000 (UTC) Received: (qmail 86094 invoked by uid 500); 21 Nov 2015 08:41:29 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 86043 invoked by uid 500); 21 Nov 2015 08:41:29 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Received: (qmail 86031 invoked by uid 99); 21 Nov 2015 08:41:29 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 21 Nov 2015 08:41:29 +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 16C381A2477 for ; Sat, 21 Nov 2015 08:41:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=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-us-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id im_Fmo80L_V8 for ; Sat, 21 Nov 2015 08:41:15 +0000 (UTC) Received: from mail-io0-f182.google.com (mail-io0-f182.google.com [209.85.223.182]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 23C13232B5 for ; Sat, 21 Nov 2015 08:41:15 +0000 (UTC) Received: by iofh3 with SMTP id h3so146355090iof.3 for ; Sat, 21 Nov 2015 00:41:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=1YFH8LnYhxhUFG76Z48XIA7bQiUrxEA25l1jnNcOMjE=; b=H73Mf3SEahv65p/y39pY0ahvOmrEJcaCEfmDDa5OlnflTlaX/soGmQOj7QEqT+TwaK LVBFaFda8KlL7+EEgZdQZoJBRpYCujQs6soRUElGmmNEB/imXxdBi8M3WP6ZT/iLf3g2 7nijb551E4kmOagbAdfsx0+0hsMd+bGA7lyFp78fWAK8QIYxX2kQ/eiLBomrZ6QEaA+3 Kgak1OBIBrN0UFuKDZwZcrSTU+LbamyBkUM/PdvgFQa43SQT8rodZNTVRpzVJuQNvumv Iei99L8E1WpQi7LknUhmLRlKa4AiUjv43xhaLy+7nXqhr6jvnZ0S8EuGCZ1ZpkdQfTTK /heQ== X-Received: by 10.107.159.199 with SMTP id i190mr16288417ioe.29.1448095274658; Sat, 21 Nov 2015 00:41:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.117.85 with HTTP; Sat, 21 Nov 2015 00:40:55 -0800 (PST) In-Reply-To: References: From: Claus Ibsen Date: Sat, 21 Nov 2015 09:40:55 +0100 Message-ID: Subject: Re: Camel ThreadPool maxQueueSize question To: "users@camel.apache.org" Content-Type: text/plain; charset=UTF-8 Set queue size to 0 or -1 or to have no queue and a direct handover with that synchronous queue. And then configure the rejected policy to decide what to do if there is no free threads, such as reject or use current thread etc. On Fri, Nov 20, 2015 at 11:09 PM, David Hoffer wrote: > This part I'm not clear on and it raises more questions. > > When using the JDK one generally uses the Executors factory methods to > create either a Fixed, Single or Cached thread tool. These will use a > SynchronousQueue for Cached pools and LinkedBlockingQueue for Fixed or > Single pools. In the case of SynchronousQueue there is no size...it simply > hands the new request off to either a thread in the pool or it creates a > new one. And in the case of LinkedBlockingQueue it uses an unbounded queue > size. Now it is possible to create a hybrid, e.g. LinkedBlockingQueue with > a max size but its not part of the factory methods or common. Another > option is the ArrayBlockingQueue which does use a max size but none of the > factory methods use this type. > > So what type of thread pool does Camel create for the default thread pool? > Since its not fixed size I assumed it would use SynchronousQueue and not > have a separate worker queue. However if Camel is creating a hybrid using > a LinkedBlockingQueue or ArrayBlockingQueue is there a way I can change > that to be a SynchronousQueue so no queue? Or is there a compelling reason > to use LinkedBlockingQueue in a cached pool? > > Now this gets to the problem I am trying to solve. We have a Camel app > that deals with files, lots of them...e.g. all the routes deal with files. > It starts with an sftp URL that gets files off a remote server and then > does a lot of subsequent file processing. The problem is that if the SFTP > server has 55 files (example) and I start the Camel app it processes them > fine until about 14 or 15 files are left and then it just stops. The > thread that does the polling of the server stops (at least it appears to > have stopped) and the processing of the 55 files stops, e.g. it does not > continue to process all of the original 55 files, it stops with 14-15 left > to process (and it never picks them up again on the next poll). And I have > a breakpoint on my custom SftpChangedExclusiveReadLockStrategy and it never > is called again. > > Now getting back to the default thread pool and changing it I would like to > change it so it uses more threads and no worker queue (like a standard > Executors cached thread pool) but I'm not certain that would even help as > in the debugger & thread dumps I see that it looks like the SFTP endpoint > uses a Scheduled Thread Pool instead which makes sense since its a polling > (every 60 seconds in my case) operation. So is there another default pool > that I can configure for Camel's scheduled threads? > > All that being said why would the SFTP endpoint just quit? I don't see any > blocked threads and no deadlock. I'm new to Camel and just don't know > where to look for possible causes of this. > > Thanks, > -Dave > > > On Thu, Nov 19, 2015 at 11:40 PM, Claus Ibsen wrote: > >> Yes its part of JDK as it specifies the size of the worker queue, of >> the thread pool (ThreadPoolExecutor) >> >> For more docs see >> http://camel.apache.org/threading-model.html >> >> Or the Camel in Action books >> >> >> On Fri, Nov 20, 2015 at 12:22 AM, David Hoffer wrote: >> > I'm trying to understand the default Camel Thread Pool and how the >> > maxQueueSize is used, or more precisely what's it for? >> > >> > I can't find any documentation on what this really is or how it's used. >> I >> > understand all the other parameters as they match what I'd expect from >> the >> > JDK...poolSize is the minimum threads to keep in the pool for new tasks >> and >> > maxPoolSize is the maximum number of the same. >> > >> > So how does maxQueueSize fit into this? This isn't part of the JDK >> thread >> > pool so I don't know how Camel uses this. >> > >> > The context of my question is that we have a from sftp route that seems >> to >> > be getting thread starved. E.g. the thread that polls the sftp >> connection >> > is slowing/stopping at times when it is busy processing other files that >> > were previously downloaded. >> > >> > We are using the default camel thread pool that I see has only a max of >> 20 >> > threads yet a maxQueueSize of 1000. That doesn't make any sense to me >> > yet. I would think one would want a much larger pool of threads (as we >> are >> > processing lots of files) but no queue at all...but not sure on that as I >> > don't understand how the queue is used. >> > >> > -Dave >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >> -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2