Re: Catch and handle errors when using the TransactionErrorHandler
On Mon, Mar 9, 2009 at 9:28 AM, Henric Hedin hhe...@gmail.com wrote: OK, I had missed that warning :) I'm using WebSphere MQ 6.0.2.5, Camel 1.6.0 and Spring 2.5.6. I'm not running XA or inside a J2EE Container, but the cacheLevelName=CACHE_NONE seems to have solved by problem for WebSphere MQ. Thanks. I have added you case to the warning. /Henric On Mon, Mar 9, 2009 at 9:11 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Mon, Mar 9, 2009 at 9:02 AM, Henric Hedin hhe...@gmail.com wrote: Hi again, I solved my problem by setting cacheLevelName=CACHE_NONE on the MQ JMS Endpoint. Now the message is backed out out directly, without the route/JVM restart. Great We have a warning about it here: http://camel.apache.org/jms.html Maybe we should add WMQ to the list as well that could have problems as well? BTW Which versions of Camel, Spring and WMQ are you using? Regards, Henric On Mon, Mar 9, 2009 at 8:53 AM, Henric Hedin hhe...@gmail.com wrote: Thank you Claus, the trick to not use the Spring Policy works good enough for me! Though, I still get a strange behavior. I'm using WebSphere MQ as the incoming JMS-provider and for the input queue I have set Backout requeue queue and the Backout threshold to 1. When sending a message to the input queue which causes a parse exception, the message is removed from the input queue and I could see on the queue depth is increased for the backout-queue; but's its never committed (i.e. I can't see the message when browsing the queue). When stopping my Route builder-flow/JVM the message is put back on the input queue and the backout count equals 2. Then, when I restart the flow/JVM again, the message is finally put correctly to the Backout queue (and removed from the input-queue), without any exceptions occurring in my Camel Route. Could this have anything to do with the JMS (Spring) options or could it be related to pooling in my (WMQ) connection factory? I will probably make some further investigations and probably try AMQ instead to see if I get the same behavior. Thanks, Henric On Fri, Mar 6, 2009 at 5:10 PM, Claus Ibsen claus.ib...@gmail.com wrote: On Fri, Mar 6, 2009 at 1:51 PM, Henric Hedin hhe...@gmail.com wrote: Hi, Is it possible to in some way to use the TransactionErrorHandler and at the same time catch and handle exceptions? I have read the documentation under http://camel.apache.org/error-handling-in-camel.html that for transactional exchanges the Error Handler does not kick, so the following code in my Route configure will not work: errorHandler(bean(TransactionErrorHandlerBuilder.class, transactionErrorHandler)); onException(SAXParseException.class). handled(true). policy(notsupported). maximumRedeliveries(1). transform().constant(Sorry, parse exception...). to(jms:queue:validationFailed.SAXParseException); from(jms:queue:input-queue?transacted=true). unmarshal(jaxbDataFormat). to(jms:queue:output-queue). What I'm trying to accomplish is if a parsing exception occurs, I would like my incoming message to be rolled back and put on the jms deadletter queue (configured for the queue on the JMS provider, when the JMSXDeliveryCount has reached it's threshold). But I would also be able to send an information jms-message to the same jms-provider with information about why the message has been backed out (of course outside the incoming transaction). Maybe a strange solution, but is it possible to handle in Camel? :) /Henric No the DeadLetterChannel is disabled for transacted exchanges. There is a trick though, if you dont add the Spring Policy then it will default to REQUIRED and still use DLC. We are considering how we can provide options for end users in the future so you can use DLC for somerthing combined with transacted exchanges. The problem with transacted exchanges is that they are redelivered in a totally new thread so Camel has no wait of correlating a previous attempt, we can only rely on the few JMS options you get such as the JMSX counter. But we dont know when we have reached exhausted, to send the extra JMS message But any feedback and ideas is welcome what we can do in the future to bring more value to error handling with TX -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/
Re: Are durable topic subscriptions destroyed?
Spring Issue created: http://jira.springframework.org/browse/SPR-5552 Claus Ibsen-2 wrote: On Thu, Mar 5, 2009 at 12:33 PM, akuhtz andreas.ku...@siemens.com wrote: There is currently no code to unsubscribe a durable subscriber as Camel uses the XXMessageListenerContainer classes from the spring framework and inside the spring code there is no unsubscribe code. I solved this yesterday by making a copy of the (in my case) SimpleMessageListenerContainer and added the unsubscribe code to the doShutdown() method (I couldn't just extend from SimpleMessageListenerContainer and overwrite doShutdown() because the consumers are private and no protected access method exists, and between close the consumers and close the session there is (unfortunately) no callback where the unsubcribe could be executed. If you find another solution without copying the class please let me know :-) You could consider creating a ticket at Spring about this issue to allow easier subclassing of the SimpleMessageListenerContainer, or callbacks so we can do the unsubscribe there. Would be good to get in Spring 3.0. Claus Ibsen-2 wrote: On Thu, Mar 5, 2009 at 3:38 AM, ariekenb aaron.j.riekenb...@lmco.com wrote: If I create a durable topic subscription using the jms or activemq components (for example activemq:topic:myTopic?clientId=client1durableSubscriptionName=subscription1), does camel ever cause the durable subscription to be destroyed? In other words will camel ever cause session.unsubscribe to be called? I'm working in a situation where I'm implementing failover of a durable subscription on different machines using camel and I want to be sure the durable subscription does not get destroyed when the camel context is destroyed. Just out of curiosity, I'm also wondering how/if one can indicate he wants the durable subscription to be destroyed when the camel context is destroyed. Not to my knowledge. But I would advice you to double check the source code of camel-jms to see if there is any code that would call unsubscribe. Usually such code would be in doStop or stop methods. James Strachan who wrote the camel-jms component would be in a better position to clarify this. With your findings we should update the wiki, so please report back. As an aside there is a small bug on this web page describing durable subscriptions (http://camel.apache.org/jms.html). The first paragraph under Notes states If you wish to use durable topic subscriptions, you need to specify both clientId and durableSubscriberName. durableSubscriberName does not work. The table below has the correct property: durableSubscriptionName. Thanks for spotting this. Fixed the typo. -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22344211.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22349650.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22409437.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Are durable topic subscriptions destroyed?
2009/3/5 akuhtz andreas.ku...@siemens.com: There is currently no code to unsubscribe a durable subscriber as Camel uses the XXMessageListenerContainer classes from the spring framework and inside the spring code there is no unsubscribe code. I solved this yesterday by making a copy of the (in my case) SimpleMessageListenerContainer and added the unsubscribe code to the doShutdown() method (I couldn't just extend from SimpleMessageListenerContainer and overwrite doShutdown() because the consumers are private and no protected access method exists, and between close the consumers and close the session there is (unfortunately) no callback where the unsubcribe could be executed. If you find another solution without copying the class please let me know :-) BTW whether the subscription is closed using an unsubscribe or if the process hosting the consumer just dies - its the same thing from a JMS provider's perspective. i.e. closing a durable topic subscriber does not terminate the durable subscription. The whole point of a durable topic subscription is to keep going while the consumer is not running any more. There's no JMS API to terminate a durable subscription - unfortunately thats JMS provider specific and usually achieved using MBeans or some provider specific console -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
Re: Are durable topic subscriptions destroyed?
I know that this is the case with ActiveMQ (you posted about it some time ago in this forum) but we're using Oracle AQ (Streams replication) and their samples show how they think it should work and in their case the unsubscribe stops the delivery of messages. James.Strachan wrote: 2009/3/5 akuhtz andreas.ku...@siemens.com: There is currently no code to unsubscribe a durable subscriber as Camel uses the XXMessageListenerContainer classes from the spring framework and inside the spring code there is no unsubscribe code. I solved this yesterday by making a copy of the (in my case) SimpleMessageListenerContainer and added the unsubscribe code to the doShutdown() method (I couldn't just extend from SimpleMessageListenerContainer and overwrite doShutdown() because the consumers are private and no protected access method exists, and between close the consumers and close the session there is (unfortunately) no callback where the unsubcribe could be executed. If you find another solution without copying the class please let me know :-) BTW whether the subscription is closed using an unsubscribe or if the process hosting the consumer just dies - its the same thing from a JMS provider's perspective. i.e. closing a durable topic subscriber does not terminate the durable subscription. The whole point of a durable topic subscription is to keep going while the consumer is not running any more. There's no JMS API to terminate a durable subscription - unfortunately thats JMS provider specific and usually achieved using MBeans or some provider specific console -- James --- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/ -- View this message in context: http://www.nabble.com/Are-durable-topic-subscriptions-destroyed--tp22344211p22411405.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
Re: Camel in Batch Processing.
Hi Christian, I've got a sample of a batch file/ftp processor in my demo up on http://fusesource.com/wiki/display/ProdInfo/FUSE+ESB+4+Getting+Started+Tutorial+Downloads Maybe that might help? /Ade On 7 Mar 2009, at 14:31, thabach wrote: Heya would you recommend using Camel in a Batch Processing scenario involving the reading of some files at the end of a business day, combining data and producing some output file ? Is there a sample, tutorial or any pointers on how such batch processing could be bootstrapped (with reference data for validation, enhancement) and triggered ? Thanks, Christian -- View this message in context: http://www.nabble.com/Camel-in-Batch-Processing.-tp22388071p22388071.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com. --- Adrian Trenaman, Consultant Fellow, PS - Opensource Center of Competence Progress Software Corp Shelbourne Road, Dublin 4, Ireland --- +353-1-637-2659 (Office) +353-1-637-2882 (Fax) +353-86-6051026 (Mobile) adrian.trenaman (Skype) Blog: http://trenaman.blogspot.com
Camel 2.0 ActiveMq: connection refused (tcp://localhost:61616) !!
Hi, Can someone tell me why I receive the following error : 2009-03-09 14:23:07,921 DEBUG TcpTransport - Stopping transport tcp://null:0 2009-03-09 14:23:07,921 DEBUG DefaultMessageListenerContainer - Could not establish shared JMS Connection - leaving it up to asynchronous invokers to establish a Connection as soon as possible javax.jms.JMSException: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused: connect at org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:35) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:280) at org.apache.activemq.ActiveMQConnectionFactory.createActiveMQConnection(ActiveMQConnectionFactory.java:224) at org.apache.activemq.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:172) at org.apache.activemq.pool.PooledConnectionFactory.createConnection(PooledConnectionFactory.java:125) at org.apache.activemq.pool.PooledConnectionFactory.createConnection(PooledConnectionFactory.java:110) at org.apache.activemq.pool.PooledConnectionFactory.createConnection(PooledConnectionFactory.java:81) at org.springframework.jms.support.JmsAccessor.createConnection(JmsAccessor.java:184) at org.springframework.jms.listener.AbstractJmsListeningContainer.createSharedConnection(AbstractJmsListeningContainer.java:378) at org.springframework.jms.listener.AbstractJmsListeningContainer.establishSharedConnection(AbstractJmsListeningContainer.java:346) at org.springframework.jms.listener.DefaultMessageListenerContainer.establishSharedConnection(DefaultMessageListenerContainer.java:678) at org.springframework.jms.listener.AbstractJmsListeningContainer.doStart(AbstractJmsListeningContainer.java:258) at org.springframework.jms.listener.AbstractJmsListeningContainer.initialize(AbstractJmsListeningContainer.java:171) at org.springframework.jms.listener.AbstractPollingMessageListenerContainer.initialize(AbstractPollingMessageListenerContainer.java:204) at org.springframework.jms.listener.DefaultMessageListenerContainer.initialize(DefaultMessageListenerContainer.java:459) at org.springframework.jms.listener.AbstractJmsListeningContainer.afterPropertiesSet(AbstractJmsListeningContainer.java:134) at org.apache.camel.component.jms.JmsConsumer.doStart(JmsConsumer.java:57) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org.apache.camel.impl.RouteService.startChildService(RouteService.java:95) at org.apache.camel.impl.RouteService.doStart(RouteService.java:79) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:744) at org.apache.camel.spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org.apache.camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org.apache.camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java:95) at org.apache.camel.spring.SpringCamelContext.onApplicationEvent(SpringCamelContext.java:114) at org.springframework.context.event.SimpleApplicationEventMulticaster$1.run(SimpleApplicationEventMulticaster.java:78) at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:76) at org.springframework.context.support.AbstractApplicationContext.publishEvent(AbstractApplicationContext.java:274) at org.springframework.context.support.AbstractApplicationContext.finishRefresh(AbstractApplicationContext.java:736) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:383) at org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:139) at org.springframework.context.support.ClassPathXmlApplicationContext.init(ClassPathXmlApplicationContext.java:93) at org.apache.camel.spring.Main.createDefaultApplicationContext(Main.java:232) at org.apache.camel.spring.Main.doStart(Main.java:186) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org.apache.camel.util.MainSupport.run(MainSupport.java:121) at org.apache.camel.util.MainSupport.run(MainSupport.java:299) at org.apache.camel.spring.Main.main(Main.java:98) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at
Re: Camel 2.0 ActiveMq: connection refused (tcp://localhost:61616) !!
Hi Charles, Yup - you don't have a broker started ,so it can't make the connect when you use tcp://localhost:61616 as the broker Url. When you use the vm://localhost URL, ActiveMQ will lazily create a broker for you in the current JVM, so that's why it's working in that case. Best, Ade On 9 Mar 2009, at 13:42, cmoulliard wrote: Hi, Can someone tell me why I receive the following error : 2009-03-09 14:23:07,921 DEBUG TcpTransport - Stopping transport tcp://null:0 2009-03-09 14:23:07,921 DEBUG DefaultMessageListenerContainer - Could not establish shared JMS Connection - leaving it up to asynchronous invokers to establish a Connection as soon as possible javax.jms.JMSException: Could not connect to broker URL: tcp://localhost:61616. Reason: java.net.ConnectException: Connection refused: connect at org .apache .activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:35) at org .apache .activemq .ActiveMQConnectionFactory .createActiveMQConnection(ActiveMQConnectionFactory.java:280) at org .apache .activemq .ActiveMQConnectionFactory .createActiveMQConnection(ActiveMQConnectionFactory.java:224) at org .apache .activemq .ActiveMQConnectionFactory .createConnection(ActiveMQConnectionFactory.java:172) at org .apache .activemq .pool .PooledConnectionFactory .createConnection(PooledConnectionFactory.java:125) at org .apache .activemq .pool .PooledConnectionFactory .createConnection(PooledConnectionFactory.java:110) at org .apache .activemq .pool .PooledConnectionFactory .createConnection(PooledConnectionFactory.java:81) at org .springframework .jms.support.JmsAccessor.createConnection(JmsAccessor.java:184) at org .springframework .jms .listener .AbstractJmsListeningContainer .createSharedConnection(AbstractJmsListeningContainer.java:378) at org .springframework .jms .listener .AbstractJmsListeningContainer .establishSharedConnection(AbstractJmsListeningContainer.java:346) at org .springframework .jms .listener .DefaultMessageListenerContainer .establishSharedConnection(DefaultMessageListenerContainer.java:678) at org .springframework .jms .listener .AbstractJmsListeningContainer .doStart(AbstractJmsListeningContainer.java:258) at org .springframework .jms .listener .AbstractJmsListeningContainer .initialize(AbstractJmsListeningContainer.java:171) at org .springframework .jms .listener .AbstractPollingMessageListenerContainer .initialize(AbstractPollingMessageListenerContainer.java:204) at org .springframework .jms .listener .DefaultMessageListenerContainer .initialize(DefaultMessageListenerContainer.java:459) at org .springframework .jms .listener .AbstractJmsListeningContainer .afterPropertiesSet(AbstractJmsListeningContainer.java:134) at org.apache.camel.component.jms.JmsConsumer.doStart(JmsConsumer.java: 57) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org .apache.camel.impl.RouteService.startChildService(RouteService.java: 95) at org.apache.camel.impl.RouteService.doStart(RouteService.java:79) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org .apache .camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:744) at org .apache .camel .spring.SpringCamelContext.maybeDoStart(SpringCamelContext.java:165) at org .apache .camel.spring.SpringCamelContext.doStart(SpringCamelContext.java:160) at org.apache.camel.impl.ServiceSupport.start(ServiceSupport.java:50) at org .apache .camel.spring.SpringCamelContext.maybeStart(SpringCamelContext.java: 95) at org .apache .camel .spring .SpringCamelContext.onApplicationEvent(SpringCamelContext.java:114) at org.springframework.context.event.SimpleApplicationEventMulticaster $1.run(SimpleApplicationEventMulticaster.java:78) at org .springframework .core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:49) at org .springframework .context .event .SimpleApplicationEventMulticaster .multicastEvent(SimpleApplicationEventMulticaster.java:76) at org .springframework .context .support .AbstractApplicationContext .publishEvent(AbstractApplicationContext.java:274) at org .springframework .context .support .AbstractApplicationContext .finishRefresh(AbstractApplicationContext.java:736) at org .springframework .context .support .AbstractApplicationContext.refresh(AbstractApplicationContext.java: 383) at org .springframework .context .support .ClassPathXmlApplicationContext .init(ClassPathXmlApplicationContext.java:139) at org .springframework .context .support .ClassPathXmlApplicationContext .init(ClassPathXmlApplicationContext.java:93) at org
Camel-Mina Request/Response correlation
Hi. I have a multithreaded environment using Camel's Mina component with Spring Remoting as following: camel:camelContext camel:proxy id=test_client serviceInterface=a.b.c.TestService serviceUrl=direct:test_service/ camel:route id=test_service_mina_route camel:from uri=direct:test_service/ camel:to uri=mina:tcp://localhost:8000?textline=falseamp;minaLogger=trueamp;timeout=10amp;lazySessionCreation=trueamp;sync=trueamp;exchangePattern=InOutamp;transferExchange=true/ /camel:route /camel:camelContext I am getting unexpected results. One calling thread consumes a result intended for different calling thread, etc. It looks like there is no correlation between request and response. I am using camel 1.6.0. Did anybody encounter similar problem? What am i missing and what is a solution for this issue? Thanks in advance. -- View this message in context: http://www.nabble.com/Camel-Mina-Request-Response-correlation-tp22413710p22413710.html Sent from the Camel - Users mailing list archive at Nabble.com.
Adding custom mbeans to camel JMX mbeanserver
Hello, I have custom endpoints developed that I would like to expose as mbeans through JMX. Currently, only the attributes of ManagedEndpoint show up. What is the easiest way to get a custom endpoint exposed in jmx while piggy-backing off the existing mbean server/naming strategy/etc supplied by camel? -- View this message in context: http://www.nabble.com/Adding-custom-mbeans-to-camel-JMX-mbeanserver-tp22421517p22421517.html Sent from the Camel - Users (activemq) mailing list archive at Nabble.com.
