Return-Path: Delivered-To: apmail-camel-users-archive@www.apache.org Received: (qmail 73256 invoked from network); 5 Nov 2009 07:28:06 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 5 Nov 2009 07:28:06 -0000 Received: (qmail 93048 invoked by uid 500); 5 Nov 2009 07:28:06 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 92963 invoked by uid 500); 5 Nov 2009 07:28:05 -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 92953 invoked by uid 99); 5 Nov 2009 07:28:05 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Nov 2009 07:28:05 +0000 X-ASF-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of willem.jiang@gmail.com designates 209.85.210.203 as permitted sender) Received: from [209.85.210.203] (HELO mail-yx0-f203.google.com) (209.85.210.203) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Nov 2009 07:28:01 +0000 Received: by yxe41 with SMTP id 41so19998489yxe.30 for ; Wed, 04 Nov 2009 23:27:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FXU+z+PLtLReGsSVhnnqKLs6fdDTq+H0Yi2WlBfHFvE=; b=tbI485tliCpZCsfvXfFgNsbsfqsn+S1Uas5kzRmupj83yhpksaordroKa0Dr2R1COT VcfjTaon0qrrrwjYh0V5u0otWaGVmS21vfiXHLK0lPoYIp4l4mFW0LnoYXlCAM0Jvmdq s//WqkX+OBrVSoBJaDgungYqaA2QxwFguFyuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=ASiUrXKB86fzqJgTNQoAlIvSTQvKk+F11KiAwHTAI+TPGwaKnU+w4xMDeuP2Jm/hYU sTpHFxLdpqtxyf3CN8Cng5uT3kx0KqbsI9cxkNtss2LEqp1KzCDNKWjqLe9a2HRgGhan UfEwI1pTrUbFBWBuPZ2qAfHWoG7EvVl7iOVIY= Received: by 10.150.118.36 with SMTP id q36mr4540831ybc.277.1257406060083; Wed, 04 Nov 2009 23:27:40 -0800 (PST) Received: from ?192.168.0.158? ([125.34.0.19]) by mx.google.com with ESMTPS id 14sm235474gxk.10.2009.11.04.23.27.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Nov 2009 23:27:38 -0800 (PST) Message-ID: <4AF27E62.5070302@gmail.com> Date: Thu, 05 Nov 2009 15:27:30 +0800 From: Willem Jiang User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: users@camel.apache.org Subject: Re: AW: AW: AW: AW: Problem with SOAP/JMS and transactions References: <5380c69c0911020408u22a0f9e7icfaf3a39e0edaedb@mail.gmail.com> <4AEED30F.2050409@gmail.com> <4AEEDE31.70407@gmail.com> <5380c69c0911020556o364685cfx1306258a4f68cdc1@mail.gmail.com> <4AEEEF49.20203@gmail.com> <4AF0EC05.7040700@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Christian, If I remember right, camel-jms component have trouble to get the message from queue and send the message to another queue if you enable the transaction. So, maybe the option 1 is a way you should look for. Willem Schneider Christian wrote: > Hi Willem, > > that is fine with me. I have closed the ticket. > > I have another exception problem though. I want to define a rule for the > other exceptions that should not return a fault. I want these exceptions to > be forwarded into something like a dead letter queue after some retries. > > I see two different ways to achieve this. > > 1) I could simply let them be rolled back and then use a filter for the jms > header JMSXDeliveryCount>n. So I could route any message that is redelivered > for the n�th time to a dead letter queue. > > 2) I could use an onException clause like below. To let camel do the > redeliveries and send to a dead letter queue after 4 tries. > > uri="jms://queue.net.enbw.services.etg.examples.customerservice.CustomerServ > ice" /> > > java.lang.Exception > > true > > > > > > > > I have not yet done 1) but have a problem with 2). It seems that when I set > handled to true then the "to" part is not executed. If I leave out "handled" > then the message is put into the deadLetter queue but rolled back later. > The only way I was able to really send to the deadLetter queue wasby turning > of transactions completely. > > Any idea what I am doing wrong? > > Greetings > > Christian > > > Christian Schneider > Team Handel und Risikomanagement > Informationsverarbeitung Business Solutions Trading > EnBW Systeme Infrastruktur Support GmbH > > Informationsverarbeitung > Business Solutions > Handel und Dispatching > Durlacher Allee 93 > 76131 Karlsruhe > > Tel : +49-(0)721-63-15482 > Mail: christian.schneider@enbw.com > > Sitz der Gesellschaft: Karlsruhe > Handelsregister: Amtsgericht Mannheim HRB 108550 > Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck > Gesch�ftsf�hrer: Jochen Adenau, Dr. Peter Krampf > > -----Urspr�ngliche Nachricht----- > Von: Willem Jiang [mailto:willem.jiang@gmail.com] > Gesendet: Mittwoch, 4. November 2009 03:51 > An: users@camel.apache.org > Betreff: Re: AW: AW: AW: Problem with SOAP/JMS and transactions > > Hi Christian, > > I saw the issue and submitted a patch for it. > BTW, I think onException is a good way to resolve your customer > exception issue. > > Willem > Schneider Christian wrote: >> Hi Willem, >> >> I have built a camel-cxf module that includes your patch. Now the rollback >> basically works. >> The problem is that it happens for all exceptions. I think a good default >> would be to return a fault for all exceptions that the service explicitly >> defines and roll back for all other exceptions. The problem is I have no >> idea how this could be done. >> >> In the meantime I will try to use a onException() clause to do this >> differentiation. >> >> I have also created a jira issue for the whole problem. >> https://issues.apache.org/activemq/browse/CAMEL-2128 >> >> >> Greetings >> >> Christian >> >> Christian Schneider >> Team Handel und Risikomanagement >> Informationsverarbeitung Business Solutions Trading >> EnBW Systeme Infrastruktur Support GmbH >> >> Informationsverarbeitung >> Business Solutions >> Handel und Dispatching >> Durlacher Allee 93 >> 76131 Karlsruhe >> >> Tel : +49-(0)721-63-15482 >> Mail: christian.schneider@enbw.com >> >> Sitz der Gesellschaft: Karlsruhe >> Handelsregister: Amtsgericht Mannheim HRB 108550 >> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck >> Gesch�ftsf�hrer: Jochen Adenau, Dr. Peter Krampf >> >> -----Urspr�ngliche Nachricht----- >> Von: Willem Jiang [mailto:willem.jiang@gmail.com] >> Gesendet: Montag, 2. November 2009 15:40 >> An: users@camel.apache.org >> Betreff: Re: AW: AW: Problem with SOAP/JMS and transactions >> >> Hi Christian, >> >> I'm glade it works on camel side. >> For the CXF side , I think we need to check the CXF message's exception >> in the Camel transport and let camel throw the exception. >> >> Here is my patch on the latest trunk code (not be verified yet), please >> feel free to give it a try. >> >> ### Eclipse Workspace Patch 1.0 >> #P camel-cxf >> Index: >> > src/main/java/org/apache/camel/component/cxf/transport/CamelDestination.java >> =================================================================== >> --- >> > src/main/java/org/apache/camel/component/cxf/transport/CamelDestination.java >> (revision 831871) >> +++ >> > src/main/java/org/apache/camel/component/cxf/transport/CamelDestination.java >> (working copy) >> @@ -271,6 +271,12 @@ >> >> propagateResponseHeadersToCamel(outMessage, camelExchange); >> >> + // check if the outMessage has an exception >> + Exception exception = outMessage.getContent(Exception.class); >> + if (exception != null) { >> + camelExchange.setException(exception); >> + } >> + >> CachedOutputStream outputStream = >> (CachedOutputStream)outMessage.getContent(OutputStream.class); >> camelExchange.getOut().setBody(outputStream.getBytes()); >> getLogger().log(Level.FINE, "send the response message: " >> + outputStream); >> >> >> >> Schneider Christian wrote: >>> Hi Claus, >>> >>> I have replaced the cxf server with the folowing route: >>> >>> >> > uri="jms://queue.net.enbw.services.etg.examples.customerservice.CustomerServ >>> ice" /> >>> >>> >>> >>> >>> Inside the Processor I simply throw a RuntimeException again. This >>> configuration works like expected. The transaction is rolled back and the >>> message gets redelivered. I also had to configure my queue now for >>> maxRedeliveries to avoid a endless loop. >>> >>> Btw. I think the redlivery could also be easily controlled inside camel > as >>> Tibco sets the property JMSXDeliveryCount. So I think this could also be >>> handled in the route if the developer has no access to the jms server >>> config. >>> >>> So this part works great. >>> >>> Thanks already for your help >>> >>> Christian >>> >>> Christian Schneider >>> Team Handel und Risikomanagement >>> Informationsverarbeitung Business Solutions Trading >>> EnBW Systeme Infrastruktur Support GmbH >>> >>> Informationsverarbeitung >>> Business Solutions >>> Handel und Dispatching >>> Durlacher Allee 93 >>> 76131 Karlsruhe >>> >>> Tel : +49-(0)721-63-15482 >>> Mail: christian.schneider@enbw.com >>> >>> Sitz der Gesellschaft: Karlsruhe >>> Handelsregister: Amtsgericht Mannheim HRB 108550 >>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck >>> Gesch�ftsf�hrer: Jochen Adenau, Dr. Peter Krampf >>> >>> -----Urspr�ngliche Nachricht----- >>> Von: Claus Ibsen [mailto:claus.ibsen@gmail.com] >>> Gesendet: Montag, 2. November 2009 14:56 >>> An: users@camel.apache.org >>> Betreff: Re: AW: Problem with SOAP/JMS and transactions >>> >>> On Mon, Nov 2, 2009 at 2:47 PM, Schneider Christian >>> wrote: >>>> Hi Willem, >>>> >>>> I also suspected it has to do with CXF Wrapping the Exception and not >>> simply >>>> rethrowing it. Do you think it would help to use pure CXF JMS Transport? >>>> >>>> For the start I will try how Claus suggested to get transactions working >>>> without CXF. When this works I will try again to get Camel CXF working >>> with >>>> it. >>>> >>> You may be able to use >>> >>> // catch the exceptions here you want to rollback >>> onException(Exception.class).markRollbackOnly(); >>> >>> Which let Camel mark it as rollback in the spring TX manager. >>> >>> And which hopefully is sufficient to mark it as rollback on the JMS >>> broker even thought CXF is wrapping the exception. >>> However this requires that Camel detects the exception before CXF does :) >>> >>> And to use the latest code from trunk. >>> >>> But try out with CXF at first to get it working. >>> >>> >>>> Greetings >>>> >>>> Christian >>>> >>>> Christian Schneider >>>> Team Handel und Risikomanagement >>>> Informationsverarbeitung Business Solutions Trading >>>> EnBW Systeme Infrastruktur Support GmbH >>>> >>>> Informationsverarbeitung >>>> Business Solutions >>>> Handel und Dispatching >>>> Durlacher Allee 93 >>>> 76131 Karlsruhe >>>> >>>> Tel : +49-(0)721-63-15482 >>>> Mail: christian.schneider@enbw.com >>>> >>>> Sitz der Gesellschaft: Karlsruhe >>>> Handelsregister: Amtsgericht Mannheim HRB 108550 >>>> Vorsitzender des Aufsichtsrats: Dr. Bernhard Beck >>>> Gesch�ftsf�hrer: Jochen Adenau, Dr. Peter Krampf >>>> >>>> -----Urspr�ngliche Nachricht----- >>>> Von: Willem Jiang [mailto:willem.jiang@gmail.com] >>>> Gesendet: Montag, 2. November 2009 14:27 >>>> An: users@camel.apache.org >>>> Betreff: Re: AW: Problem with SOAP/JMS and transactions >>>> >>>> Hi Christian, >>>> >>>> I think it may relate to the CamelDestination just deal with input and >>>> output stream. >>>> As you know if you throw the exception from the service impl, the >>>> exception will be caught by the CXF interceptor chain and it will be >>>> turned into a soap fault message, then be passed back to the client. >>>> >>>> Since the CamelDestination can't know the under layer message is the >>>> fault message, it can't throw the exception to let the camel-jms >>>> component roll back. >>>> >>>> Maybe we need to find another way to resolve your issue. >>>> >>>> Willem >>>> >>>> Schneider Christian wrote: >>>>> Hi Willem, >>>>> >>>>> I have adjusted my applicationContext but still my message gets >>>> acknowledged >>>>> instead of being rolled back. >>>>> >>>>> My service impl contains: >>>>> throw new RuntimeException("Test for transaction"); >>>>> >>>>> Any idea what still goes wrong? >>>>> >>>>> Greetings >>>>> >>>>> Christian >>>>> >>>>> ---- >>>>> >>>>> My applicationcontext now looks like the following. I have also added >>>>> to the route for the server. >>>>> >>>>> >>>>> >>>>> >>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>>>> xmlns:context="http://www.springframework.org/schema/context" >>>>> xsi:schemaLocation="http://www.springframework.org/schema/beans >>>>> http://www.springframework.org/schema/beans/spring-beans-2.0.xsd >>>>> http://cxf.apache.org/core >>>>> http://cxf.apache.org/schemas/core.xsd >>>>> http://cxf.apache.org/jaxws >>>>> http://cxf.apache.org/schemas/jaxws.xsd >>>>> http://www.springframework.org/schema/context >>>>> http://www.springframework.org/schema/context/spring-context-2.5.xsd >>>>> http://camel.apache.org/schema/spring >>>>> http://camel.apache.org/schema/spring/camel-spring.xsd >>>>> http://cxf.apache.org/transports/camel >>>>> http://cxf.apache.org/transports/camel.xsd" >>>>> >>>>> >>>>> >>>>> > /> >>>>> >> /> >>>>> >>>>> >>>>> >>>> >>>>> > class="org.springframework.beans.factory.config.PropertyPlaceholderConfigure >>>>> r"> >>>>> >>>>> >>>>> classpath:jms.properties >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> xmlns="http://cxf.apache.org/jaxws" >>>>> xmlns:service="http://examples.etg.services.enbw.net/" >>>>> serviceName="service:CustomerService" >>>>> endpointName="service:CustomerServiceEndpoint" >>>>> address="camel://direct:server" >>>>> implementor="#serviceImpl"> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> xmlns:service="http://examples.etg.services.enbw.net/" >>>>> serviceName="service:CustomerService" >>>>> endpointName="service:CustomerServiceEndpoint" >>>>> >>>>> > serviceClass="net.enbw.services.etg.examples.customerservice.CustomerService >>>>> V1" >>>>> address="camel://direct:client"> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> xmlns="http://camel.apache.org/schema/spring"> >>>>> >>>>> >>>>> >>>> > uri="jms://queue.net.enbw.services.etg.examples.customerservice.CustomerServ >>>>> ice" /> >>>>> >>>>> >>>>> >>>> > uri="jms://queue.net.enbw.services.etg.examples.customerservice.CustomerServ >>>>> ice" /> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> class="org.apache.camel.component.jms.JmsComponent"> >>>>> >>>>> >>>>> >>>>> >>>> ref="jmsConnectionFactory" /> >>>>> >>>>> >>>> class="org.apache.camel.component.jms.JmsConfiguration"> >>>>> >> /> >>>>> > value="TRANSACTED" >>>>> /> >>>>> >>>>> >>>> value="${jms.receiveTimeout}" /> >>>>> >>>> value="${jms.requestTimeout}" /> >>>>> >>>> value="${jms.recoveryInterval}" /> >>>>> >>>>> >>>>> >>>>> >>>> ref="jmsTransactionManager"/> >>>>> >>>>> >>>>> >>>> class="org.springframework.jms.connection.JmsTransactionManager"> >>>>> >>>> ref="jmsConnectionFactory" /> >>>>> >>>>> >>>>> >>>>> >>>> class="com.tibco.tibjms.TibjmsConnectionFactory"> >>>>> >>>>> >>>>> >> /> >>>>> >>>> value="${jms.reconnAttemptCount}" /> >>>>> >>>> value="${jms.reconnAttemptDelay}" /> >>>>> >>>>> >>>>> >>>>> >>> >> > >