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 C9C3F18022 for ; Tue, 12 May 2015 04:56:02 +0000 (UTC) Received: (qmail 79505 invoked by uid 500); 12 May 2015 04:56:02 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 79460 invoked by uid 500); 12 May 2015 04:56:02 -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 79449 invoked by uid 99); 12 May 2015 04:56:02 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 12 May 2015 04:56:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 7E29CC41E2 for ; Tue, 12 May 2015 04:56:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.761 X-Spam-Level: X-Spam-Status: No, score=0.761 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RCVD_IN_MSPIKE_H2=-0.038, SPF_PASS=-0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 6LT_ABemBobW for ; Tue, 12 May 2015 04:56:00 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id 5F9AC24A48 for ; Tue, 12 May 2015 04:56:00 +0000 (UTC) Received: from [192.168.178.29] ([217.191.234.81]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlDb4-1ZSjpT46R4-00b7Ou for ; Tue, 12 May 2015 06:55:58 +0200 Message-ID: <555187E0.7010804@gmx.de> Date: Tue, 12 May 2015 06:56:00 +0200 From: Carsten Lohmann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: users@camel.apache.org Subject: Re: Question on Threads XML-DSL References:

In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:2shaaJTBxZUMocEmCAG0Sr9qnnuAXXg1c+CjLDlYZywHrzUeOTS p/gqNeFxwEqAIf/njg44CFea3Y3hJq55Ebye8bsBCVe/JegqhKnBJ+RUbH6nzf5ae3G7fGs nvP3TSkiD1ZaYmS0p4rO6cvHLRmEqW4lnOaxf1jn0GbNJ3FzdIcwogCPwILZHIZtNv/Uj55 HrUuoe5RpF9qmm+TmBSOQ== X-UI-Out-Filterresults: notjunk:1; Thanks for pointing to the wiretap component. Our use case was a where each loop run should be processed in parallel. First we were using a seda endpoint (with concurrentConsumers>1) but with its thread pool (and no extra queue in between) proved to be the better solution here. Am 04.05.2015 um 14:16 schrieb Claus Ibsen: > Hi > > Its like the consumer of the route being fully async so it releases > its thread at threads, and then it takes over routing. > If you want to fork off work, then use wire tap to decouple the work > from the current routing. > > On Mon, May 4, 2015 at 11:48 AM, Carsten Lohmann wrote: >> Hi, >> >> I experimented with the Threads XML-DSL and found its behaviour to be somewhat confusing. >> >> These route elements >> --------------------- >> >> >> >> >> >> >> --------------------- >> produce this output >> --------------------- >> INFO BEFORE Threads block; ThreadName: 'default-workqueue-1' >> INFO INSIDE Threads block; ThreadName: 'Camel (test) thread #10 - Threads' >> INFO AFTER Threads block; ThreadName: 'Camel (test) thread #10 - Threads' >> --------------------- >> >> It seems strange that route processing *after* the block is also done in the thread-pool thread. >> (In that sense there seems to be no point in having a " .. " block element; a single would look more appropriate.) >> >> Or is there a way for the route processing *after* the block to be done in the same thread as *before*? (I already made sure the exchange pattern was "InOnly".) >> I wanted to do some work in a separate thread (not wanting to wait for its result) and in the meantime continue with the main thread. >> Is that possible with the component? >> What happened to the "waitForTaskToComplete" option? >> >> TIA, >> Carsten > > >