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 CFB2C97DD for ; Mon, 30 Jan 2012 14:47:49 +0000 (UTC) Received: (qmail 19229 invoked by uid 500); 30 Jan 2012 14:47:49 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 19172 invoked by uid 500); 30 Jan 2012 14:47:48 -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 19164 invoked by uid 99); 30 Jan 2012 14:47:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 14:47:48 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of claus.ibsen@gmail.com designates 209.85.215.45 as permitted sender) Received: from [209.85.215.45] (HELO mail-lpp01m010-f45.google.com) (209.85.215.45) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 30 Jan 2012 14:47:42 +0000 Received: by mail-lpp01m010-f45.google.com with SMTP id i5so1865099lah.32 for ; Mon, 30 Jan 2012 06:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding; bh=C9bQyqEMMCedD+EwdmBQREjvwGYX92fv57wfSWn2Zu4=; b=Gd1tzJYvFW0USrf0DTyraZis67HGG/in/06AzhQJzocewBd3BIQ/RdeyT4sNL8sV5w m478e2CVU7mKTny0NOQg7pGZhn+pSW1EjuIIGcBGCb+zEIhBuWoykPrnuYKLNjd+o0sv SX9jiUJrJqiJ+3x28d/RaxwDN9kG7nbQ9rT3Y= Received: by 10.152.147.38 with SMTP id th6mr8979841lab.47.1327934842337; Mon, 30 Jan 2012 06:47:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.4.71 with HTTP; Mon, 30 Jan 2012 06:47:02 -0800 (PST) In-Reply-To: References: From: Claus Ibsen Date: Mon, 30 Jan 2012 15:47:02 +0100 Message-ID: Subject: Re: JMS and transaction To: users@camel.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Jan 30, 2012 at 3:41 PM, Herv=E9 BARRAULT wrote: > Hi, > thanks for the quick answer. > >> It does not support batching, not async TX, etc. > > But does it supports TX and concurrentConsumers ? > > I have to multiply the number of consumers as they are slower than the pr= oducer. > Yes. > > On 1/30/12, Claus Ibsen wrote: >> On Mon, Jan 30, 2012 at 11:05 AM, Herv=E9 BARRAULT >> wrote: >>> Hi, thanks for confirmation. >>> So for publication, i should use a transactions with sequential mechani= sm. >>> >>> I have seen also on activeMQ documentation : >>> http://activemq.apache.org/should-i-use-transactions.html : >>> Its also worth noting that if you are using persistent messaging, the >>> fastest way of using JMS is to actually use transactions and use >>> batching ... >>> >>> Is this mechanism working when using concurrentConsumer ? >>> Or should i choose between transaction and batching ? >>> >> >> The camel-jms component is baked on top of Spring JMS which is generic >> and limited in some areas. >> It does not support batching, not async TX, etc. >> >> Alot of people just use it as is, and its fast enough for their use-case= s. >> I suggest to use that, and do some testing to see if its fast enough for >> you. >> >> >> >> >>> Thanks for answers >>> >>> Regards >>> >>> Herv=E9 >>> >>> >>> On 1/28/12, Claus Ibsen wrote: >>>> Spring Transaction does not support using multiple threads. The >>>> transactional work should be done in the same thread, from spring TX >>>> manager point of view. >>>> >>>> On Fri, Jan 27, 2012 at 5:29 PM, Herv=E9 BARRAULT >>>> wrote: >>>>> Hi, >>>>> >>>>> I found in archive that parallel processing is not compatible with >>>>> transaction. >>>>> >>>>> Is it still relevant or is there a workaround ? >>>>> >>>>> Regards >>>>> >>>>> Herv=E9 >>>>> >>>>> On 1/27/12, Herv=E9 BARRAULT wrote: >>>>>> Hi, >>>>>> >>>>>> I have two question about a route, JMS and transactions. >>>>>> >>>>>> The use is : one request response Web service put message on n queue= s >>>>>> (using transaction ensure the message really put in all queues or no >>>>>> one). >>>>>> >>>>>> Does this route make sense (only "pseudo" route not all the stuff to >>>>>> manage transaction i guess) ? >>>>>> >>>>>> from("cxf:bean:myEndpoint"). >>>>>> .wireTap("direct:tap") >>>>>> .process(myProcessor) >>>>>> transacted("PROPAGATION_REQUIRES_NEW") >>>>>> .multicast() >>>>>> .parallelProcessing() >>>>>> .recipientList(header("MY_HEADER")) >>>>>> .end() >>>>>> .process(myAnswerProcessor); >>>>>> >>>>>> from(direct:tap).process(myOptionalProcessor); >>>>>> >>>>>> If it could work, when is the transaction commit ? >>>>>> >>>>>> Thanks for answers. >>>>>> >>>>>> Regards >>>>>> Herv=E9 >>>>>> >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> FuseSource >>>> Email: cibsen@fusesource.com >>>> Web: http://fusesource.com >>>> Twitter: davsclaus, fusenews >>>> Blog: http://davsclaus.blogspot.com/ >>>> Author of Camel in Action: http://www.manning.com/ibsen/ >>>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> FuseSource >> Email: cibsen@fusesource.com >> Web: http://fusesource.com >> Twitter: davsclaus, fusenews >> Blog: http://davsclaus.blogspot.com/ >> Author of Camel in Action: http://www.manning.com/ibsen/ >> --=20 Claus Ibsen ----------------- FuseSource Email: cibsen@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/