Re: Request-reply concurrency with jms in older Camel versions
I made a new test with delaying jms provider system responses by 20s, and seems that responses are being processed cuncurrently, probably because I have multiple consumer threads calling direct route: Case 1: Jms (InOnly, maxConsumers=10) - Split (pool of 10-20 threads) - Custom component/endpoint/producer with parent (referenced) endpoint/producer set as Direct route - Direct InOut route - Jms (InOut, maxConsumers=10), or Case 2: Jms (InOnly, maxConsumers=10) - Split (pool of 10-20 threads) - Custom component/endpoint/producer with parent (referenced) endpoint/producer set as Jms endpoint - Jms (InOut, maxConsumers=10) Here are logs for the second case, logging is done inside custom producer around going into parent producer (jms) and receiving responses (responses from provider system delayed for 20s). 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer42.Camel (process) thread #5 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer41.Camel (process) thread #4 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer47.Camel (process) thread #10 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer38.Camel (process) thread #1 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer43.Camel (process) thread #6 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer39.Camel (process) thread #2 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer40.Camel (process) thread #3 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer44.Camel (process) thread #7 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer46.Camel (process) thread #9 - Split 2014-08-28 10:14:09 INFO EsbRedeliveryProducer: before parentProducer45.Camel (process) thread #8 - Split 2014-08-28 10:14:33 INFO EsbRedeliveryProducer: after parentProducer40.Camel (process) thread #3 - Split 2014-08-28 10:14:33 INFO EsbRedeliveryProducer: after parentProducer42.Camel (process) thread #5 - Split 2014-08-28 10:14:33 INFO EsbRedeliveryProducer: after parentProducer38.Camel (process) thread #1 - Split 2014-08-28 10:14:33 INFO EsbRedeliveryProducer: before parentProducer40.Camel (process) thread #3 - Split 2014-08-28 10:14:34 INFO EsbRedeliveryProducer: before parentProducer42.Camel (process) thread #5 - Split 2014-08-28 10:14:34 INFO EsbRedeliveryProducer: after parentProducer46.Camel (process) thread #9 - Split 2014-08-28 10:14:36 INFO EsbRedeliveryProducer: after parentProducer44.Camel (process) thread #7 - Split 2014-08-28 10:14:37 INFO EsbRedeliveryProducer: after parentProducer41.Camel (process) thread #4 - Split 2014-08-28 10:14:37 INFO EsbRedeliveryProducer: before parentProducer38.Camel (process) thread #1 - Split 2014-08-28 10:14:38 INFO EsbRedeliveryProducer: after parentProducer43.Camel (process) thread #6 - Split 2014-08-28 10:14:39 INFO EsbRedeliveryProducer: after parentProducer45.Camel (process) thread #8 - Split 2014-08-28 10:14:41 INFO EsbRedeliveryProducer: after parentProducer39.Camel (process) thread #2 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: after parentProducer47.Camel (process) thread #10 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer46.Camel (process) thread #9 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer43.Camel (process) thread #6 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer39.Camel (process) thread #2 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer41.Camel (process) thread #4 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer45.Camel (process) thread #8 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer44.Camel (process) thread #7 - Split 2014-08-28 10:14:42 INFO EsbRedeliveryProducer: before parentProducer47.Camel (process) thread #10 - Split 2014-08-28 10:14:55 INFO EsbRedeliveryProducer: after parentProducer40.Camel (process) thread #3 - Split 2014-08-28 10:14:55 INFO EsbRedeliveryProducer: before parentProducer40.Camel (process) thread #3 - Split 2014-08-28 10:14:56 INFO EsbRedeliveryProducer: after parentProducer42.Camel (process) thread #5 - Split 2014-08-28 10:14:56 INFO EsbRedeliveryProducer: before parentProducer42.Camel (process) thread #5 - Split 2014-08-28 10:14:58 INFO EsbRedeliveryProducer: after parentProducer38.Camel (process) thread #1 - Split 2014-08-28 10:14:59 INFO
Request-reply concurrency with jms in older Camel versions
Hello, I have a problem with concurrently sending messages to InOut jms destination and processing replies using Camel 2.6.0. I cannot upgrade because of java 1.5. As I undestand, in such case there is only 1 consumer listening for the replies. I tried using thread dsl, but it didn't help, probably because there is still only 1 DefaultMessageListenerContainer which listens for the replies sinchronously and thread dsl creates threads only for processing those replies afterwards, am I right? My route: camel:route id=esbDirectRoute camel:from uri=direct:esbRoute/ camel:setExchangePattern pattern=InOut / camel:to uri=log:beforeSendingToEsb/ camel:to uri=jmsIBM:queue:REQ_QUEUE?exchangePattern=InOutamp;timeToLive=6amp;requestTimeout=6amp;receiveTimeout=100amp;concurrentConsumers=20amp;maxConcurrentConsumers=20 / camel:threads poolSize=20 maxPoolSize=20 threadName=esb-pool-thread camel:to uri=log:afterSendingToEsb/ /camel:threads /camel:route There are multiple threads calling this route. When testing with only 1 working thread the time between 2 log statemments is 1-2 s (jms provider system response time). When there are many threads like 10-20 - time between log statements increases up to 15 s. Here is log showing the start of this test: 2014-08-27 10:26:22 INFO beforeSendingToEsb 2014-08-27 10:26:22 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:23 INFO beforeSendingToEsb 2014-08-27 10:26:24 INFO afterSendingToEsb 2014-08-27 10:26:24 INFO beforeSendingToEsb 2014-08-27 10:26:25 INFO afterSendingToEsb 2014-08-27 10:26:26 INFO beforeSendingToEsb 2014-08-27 10:26:26 INFO afterSendingToEsb 2014-08-27 10:26:27 INFO beforeSendingToEsb 2014-08-27 10:26:28 INFO afterSendingToEsb 2014-08-27 10:26:28 INFO beforeSendingToEsb ... Is there any way to use concurrent response listener with Camel 1.6.0? Any way to control how Camel creates org.springframework.jms.listener.DefaultMessageListenerContainer or org.springframework.jms.listener.SimpleMessageListenerContainer in this case? Excerpt from camel jms docs: Camel will automatic setup a consumer which listen on the reply queue, so you should not do anything. This consumer is a Spring DefaultMessageListenerContainer which listen for replies. However it's fixed to 1 concurrent consumer. That means replies will be processed in sequence as there are only 1 thread to process the replies. If you want to process replies faster, then we need to use concurrency. But not using the concurrentConsumer option. We should use the threads from the Camel DSL instead Seems that this issue is addressed in Camel 2.10.3: Allows to process reply messages concurrently using concurrent message listeners in use. You can specify a range using the concurrentConsumers and maxConcurrentConsumers options. Notice: That using Shared reply queues may not work as well with concurrent listeners, so use this option with care. Thank you, Igor -- View this message in context: http://camel.465427.n5.nabble.com/Request-reply-concurrency-with-jms-in-older-Camel-versions-tp5755769.html Sent from the Camel - Users mailing list archive at Nabble.com.
Camel CXF synchronous=true setting causes CXF bean invocation last for 60 seconds or more
Hello, I'm using Camel with Servicemix (2.7.1.fuse-00-43). The problem happens when setting synchronous=true - to uri=cxf:bean:cxfBean / invocation hangs for 60 or more seconds with no obvious reason. The operation in WSDL is a one-way operation. I have also tried defining CXF bus, and using URL options: to uri=cxf://http://dummy?dataFormat=PAYLOADamp;synchronous=trueamp;wsdlURL=classpath:wsdl/aaa-bbb-CashManagement-Customer-V01.wsdlamp;bus=#cxf-callback; / but the result is the same. What are the reasons for such a delay in CXF bean call? If I select synchronous=false, then error handling is not working (as was described in the links in the comment below). 2012-07-17 *15:02:13*,477 | INFO | banktocustomerdebitcreditnotificationv02.MainRoute | Exchange[Id:ID:vavi104a-48450-1342101770302-10:105:1:1:1];ReqId[igor_test_notification_004_VALID];http://localhost:9876/cashManagement 2012-07-17 *15:03:39*,902 | DEBUG | banktocustomerdebitcreditnotificationv02.MainRoute | Exchange[Id:ID:vavi104a-48450-1342101770302-10:105:1:1:1];ReqId[igor_test_notification_004_VALID];CashManagementV01.bankToCustomerDebitCreditNotificationV02 successfully executed. Igor -- View this message in context: http://camel.465427.n5.nabble.com/Camel-CXF-synchronous-true-setting-causes-CXF-bean-invocation-last-for-60-seconds-or-more-tp5716160.html Sent from the Camel - Users mailing list archive at Nabble.com.
Processors in onException block remove message headers in certain cases
Hello, I'm using Camel with Servicemix (2.7.1.fuse-00-43) with the following route: The problems is when a system exception is thrown from CashManagementV01Endpoint, like org.apache.xml.security.encryption.XMLEncryptionException: Illegal key size (the full stacktrace is below - the reason is known and is not the subject of this issue), then onException block of the route behaves very strangely - any custom processor or log statement in it removes all headers of the message, so that any subsequent processors don't have them. This is not happenning when throwException ref=forced / is commented out in this route. Here are log statements: When the system error is thrown by CXF endpoint: 2012-07-05 15:19:49,276 | INFO | gateway.SyncDispatcherRoute | Exchange[Id:ID:lsp0396c-37215-134148838-8:5:1:1:1];ReqId[0bb6cdb7-9ce2-42fa-8db9-cf1b851c025c] 2012-07-05 15:19:49,337 | DEBUG | cashmanagementv01.InitRoute | Exchange[Id:ID:lsp0394c-59732-1341487291874-8:141:5:1:1];ReqId[0bb6cdb7-9ce2-42fa-8db9-cf1b851c025c];CashManagementV01 execution started. 2012-07-05 15:19:49,499 | ERROR | cashmanagementv01.InitRoute | BEFORE;ReqId[0bb6cdb7-9ce2-42fa-8db9-cf1b851c025c] *2012-07-05 15:19:49,499 | ERROR | cashmanagementv01.InitRoute | AFTER;ReqId[]* When throwException is used instead: 2012-07-05 15:22:52,530 | INFO | gateway.SyncDispatcherRoute | Exchange[Id:ID:lsp0396c-37215-134148838-8:6:1:1:1];ReqId[4f2b8303-674e-4853-8089-87ca096baee8] 2012-07-05 15:22:52,562 | DEBUG | cashmanagementv01.InitRoute | Exchange[Id:ID:lsp0394c-59732-1341487291874-8:141:4:1:1];ReqId[4f2b8303-674e-4853-8089-87ca096baee8];CashManagementV01 execution started. 2012-07-05 15:22:52,569 | ERROR | cashmanagementv01.InitRoute | BEFORE;ReqId[4f2b8303-674e-4853-8089-87ca096baee8] *2012-07-05 15:22:52,569 | ERROR | cashmanagementv01.InitRoute | AFTER;ReqId[4f2b8303-674e-4853-8089-87ca096baee8]* Why are message headers being removed in the first case? Igor === -- View this message in context: http://camel.465427.n5.nabble.com/Processors-in-onException-block-remove-message-headers-in-certain-cases-tp5715546.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: global onException clause wrongly identifies route in which exception occurs (log name)
Our Camel version is camel-core (2.7.1.fuse-00-43). We use Camel with
Servicemix.
I have just tested with valid message, and then invalid, here is the log
(all statements are printed):
2011-12-08 14:38:24,588 | DEBUG | customerpaymentstatusreportv03.MainRouteEE
| Exchange[Id:ID:414d512056494c3130375544202020204e9d7a712227c502,
ExchangePattern:InOnly, BodyType:String]
2011-12-08 14:38:24,611 | INFO | customerpaymentstatusreportv03.MainRouteEE
|
Exchange[Id:ID:414d512056494c3130375544202020204e9d7a712227c502];igor_test_1,igor_test
2011-12-08 14:38:24,902 | DEBUG | customerpaymentstatusreportv03.MainRouteEE
|
Exchange[Id:ID:414d512056494c3130375544202020204e9d7a712227c502];igor_test_1,igor_test;Service
successfully executed.
2011-12-08 14:39:23,235 | DEBUG | customerpaymentstatusreportv03.MainRouteEE
| Exchange[Id:ID:51756575655a6565bbd4c6d6e49aff3ab57ea2244d2b47d2,
ExchangePattern:InOnly, BodyType:byte[]]
2011-12-08 14:39:23,362 | ERROR | customerpaymentstatusreportv03.SharedRoute
| Exchange[Id:ID:51756575655a6565bbd4c6d6e49aff3ab57ea2244d2b47d2];;Error
has occurred: [B cannot be cast to org.w3c.dom.Node. Stacktrace:
java.lang.ClassCastException: [B cannot be cast to org.w3c.dom.Node
at
org.apache.xpath.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:121)
at
org.apache.xpath.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:99)
at
org.apache.xpath.jaxp.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:184)
at
org.apache.camel.builder.xml.XPathBuilder.doInEvaluateAs(XPathBuilder.java:667)
at
org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:639)
There is no place where similar error could occur in SharedRoute, here is
its complete source:
route id=customerpaymentstatusreportv03.SharedRoute
from ref=call_esb_service /
transacted ref=PROPAGATION_REQUIRED /
setExchangePattern pattern=InOnly /
setHeader headerName=ESBHeader_ServiceName
constantPaymentsInitiationCallback/constant
/setHeader
setHeader headerName=ESBHeader_ServiceOperation
constantcustomerPaymentStatusReportV03/constant
/setHeader
setHeader headerName=ESBHeader_ServiceVersion
constant1.0/constant
/setHeader
setHeader headerName=ESBHeader_ServiceUser
simple${properties:esb.user}/simple
/setHeader
setHeader headerName=ESBHeader_ServiceUserCredentials
simple${properties:esb.user.credentials}/simple
/setHeader
setHeader headerName=ESBHeader_ConsumerRequestId
simple${property.REQUEST_ID}/simple
/setHeader
to ref=queue_esb /
/route
Here are servicemix.log excerpts:
2011-12-08 14:51:04,445 | ERROR | ISO20022.VIL.MSG | DefaultErrorHandler
| ache.camel.processor.CamelLogger | 52 - org.apache.camel.camel-core -
2.7.1.fuse-00-43 | Failed delivery for exchangeId:
ID:51756575655a6565b94499f1807b17ac4fc77daff5de4e51. Exhausted after
delivery attempt: 1 caught: java.lang.ClassCastException: [B cannot be cast
to org.w3c.dom.Node. Processed by failure processor: Channel[L
og[Exchange[Id:${exchangeId}];${property.REQUEST_ID};Error has occurred:
${exception.message}. Stacktrace: ${exception.stacktrace}]]
java.lang.ClassCastException: [B cannot be cast to org.w3c.dom.Node
at
org.apache.xpath.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:121)[:]
at
org.apache.xpath.jaxp.XPathExpressionImpl.eval(XPathExpressionImpl.java:99)[:]
at
org.apache.xpath.jaxp.XPathExpressionImpl.evaluate(XPathExpressionImpl.java:184)[:]
at
org.apache.camel.builder.xml.XPathBuilder.doInEvaluateAs(XPathBuilder.java:667)[52:org.apache.camel.camel-core:2.7.1.fuse-00-43]
at
org.apache.camel.builder.xml.XPathBuilder.evaluateAs(XPathBuilder.java:639)[52:org.apache.camel.camel-core:2.7.1.fuse-00-43]
at
org.apache.camel.builder.xml.XPathBuilder.evaluate(XPathBuilder.java:612)[52:org.apache.camel.camel-core:2.7.1.fuse-00-43]
.
2011-12-08 14:51:04,465 | WARN | ISO20022.VIL.MSG | TransactionErrorHandler
| ring.spi.TransactionErrorHandler | 52 - org.apache.camel.camel-core -
2.7.1.fuse-00-43 | Transaction rollback (0xd8f459) for ExchangeId:
ID:51756575655a6565b94499f1807b17ac4fc77daff5de4e51 due exception:
java.lang.ClassCastException: [B cannot be cast to org.w3c.dom.Node
2011-12-08 14:51:04,467 | WARN | ISO20022.VIL.MSG |
JmsMessageListenerContainer | AbstractMessageListenerContainer | 66 -
org.springframework.jms - 3.0.5.RELEASE | Execution of JMS message listener
failed, and no ErrorHandler has been set.
Re: global onException clause wrongly identifies route in which exception occurs (log name)
I have just tried to throw an exception explicitly:
* route id=customerpaymentstatusreportv03.MainRouteEE*
from ref=queue_ee /
transacted ref=PROPAGATION_REQUIRED /
setExchangePattern pattern=InOnly /
to
uri=log:customerpaymentstatusreportv03.MainRouteEE?showProperties=falseamp;showExchangeId=trueamp;showHeaders=falseamp;showBody=falseamp;level=DEBUG/
* throwException ref=forced /*
setProperty propertyName=REQUEST_ID
xpath
resultType=java.lang.Stringconcat(//urn:CstmrPmtStsRpt/urn:GrpHdr/urn:MsgId,
,, //urn:CstmrPmtStsRpt/urn:OrgnlGrpInfAndSts/urn:OrgnlMsgId)/xpath
/setProperty
log
message=Exchange[Id:${exchangeId}];${property.REQUEST_ID}
loggingLevel=INFO /
to ref=call_esb_service /
log
message=Exchange[Id:${exchangeId}];${property.REQUEST_ID};Service
successfully executed. loggingLevel=DEBUG /
/route
bean id=forced class=java.lang.IllegalArgumentException
constructor-arg index=0 value=This is forced/
/bean
and results are the same:
2011-12-08 15:22:04,477 | DEBUG | customerpaymentstatusreportv03.MainRouteEE
| Exchange[Id:ID:414d512056494c3130375544202020204e9d7a7122269303,
ExchangePattern:InOnly, BodyType:String]
2011-12-08 15:22:04,482 | ERROR |
*customerpaymentstatusreportv03.SharedRoute* |
Exchange[Id:ID:414d512056494c3130375544202020204e9d7a7122269303];;Error has
occurred: This is forced. Stacktrace: java.lang.IllegalArgumentException:
This is forced
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:126)
at
org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:108)
at
org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:280)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:1003)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:907)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:485)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:291)
at
org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:222)
at
org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:288)
at
org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:190)
at
org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:580)
at
org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:895)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$1600(AbstractDelegatedExecutionApplicationContext.java:69)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$4.run(AbstractDelegatedExecutionApplicationContext.java:355)
at
org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
at
org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.completeRefresh(AbstractDelegatedExecutionApplicationContext.java:320)
at
org.springframework.osgi.extender.internal.dependencies.startup.DependencyWaiterApplicationContextExecutor$CompleteRefreshTask.run(DependencyWaiterApplicationContextExecutor.java:132)
at java.lang.Thread.run(Thread.java:662)
--
View this message in context:
http://camel.465427.n5.nabble.com/global-onException-clause-wrongly-identifies-route-in-which-exception-occurs-log-name-tp5058304p5058757.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: global onException clause wrongly identifies route in which exception occurs (log name)
Thank you. But this unit test is a little different than the original problem, the exception should be thrown from the foo route before reaching the other route. Could you please change the unit test and check the output? -- View this message in context: http://camel.465427.n5.nabble.com/global-onException-clause-wrongly-identifies-route-in-which-exception-occurs-log-name-tp5058304p5059072.html Sent from the Camel - Users mailing list archive at Nabble.com.
ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node
Hello, I have an issue similar to one described at the bottom of https://issues.apache.org/jira/browse/CAMEL-3277 I'm using Camel 2.7.0 with ServiceMix, and a spring-DSL-based Camel context with one Java bean. A route reads messages (requests) from Jetty http endpoint, then a couple of Xpath expressions follows. When I place a call to a Java bean method between them, which perform just simple String body = exchange.getIn().getBody(String.class); then the Xpath expression that follows it (the second expression) fails with an error: java.lang.ClassCastException: org.apache.camel.converter.stream.InputStreamCache cannot be cast to org.w3c.dom.Node I will post additional details tomorrow including the stacktrace, but maybe I just need to reset the InputStreamCache after the bean method completes? Or should I be able to read the message body multiple times without any special actions? Igor -- View this message in context: http://camel.465427.n5.nabble.com/ClassCastException-org-apache-camel-converter-stream-InputStreamCache-cannot-be-cast-to-org-w3c-dom-e-tp5053112p5053112.html Sent from the Camel - Users mailing list archive at Nabble.com.
ExchangeTimedOutException not properly constructed by Camel 2.7.1 exposing exchange data
Hello,
We have an issue with Camel JMS component when after receiving a timeout
(org.apache.camel.ExchangeTimedOutException) the exception's getMessage()
always contains the whole Exchange.toString() method's content, which means
it always exposes all sensitive headers that were set before sending the
message to the queue. Also, the exception's stacktrace also has
Exchange.toString() content and exposes those headers.
How can we solve this? Is there a fix planned for Camel? There should be
some boolean property which would specify that the exchange content not to
be included when constructing exceptions.
Constructor in CamelExchangeException.java uses
super(ExchangeHelper.createExceptionMessage(message, exchange, null)); where
the exception message is produced.
ReplyManagerSupport.java:
if (timeout) {
// no response, so lets set a timed out exception
exchange.setException(new
ExchangeTimedOutException(exchange, holder.getRequestTimeout()));
} else {...}
=
endpoint id=queue_esb
uri=ibmmq:ESB.REQ?replyTo=ESB.RPLamp;requestTimeout=3amp;useMessageIDAsCorrelationID=true/
setHeader headerName=ServiceUser
simple${properties:esb.user}/simple
/setHeader
setHeader headerName=ServiceUserCredentials
simple${properties:esb.user.credentials}/simple
/setHeader
to ref=queue_esb pattern=InOut /
Exception originalException =
exchange.getProperty(Exchange.EXCEPTION_CAUGHT, Exception.class);
LOGGER.info(Original Exception stacktrace: +
getStackTrace(originalException));
public static String getStackTrace(Throwable aThrowable) {
final Writer result = new StringWriter();
final PrintWriter printWriter = new PrintWriter(result);
aThrowable.printStackTrace(printWriter);
return result.toString();
}
==
2011-11-07 17:07:52,833 | INFO | accountreportingrequestv02.UtilitiesBean |
*Original Exception stacktrace:* org.apache.camel.ExchangeTimedOutException:
The OUT message was not received within: 3 millis. Exchange[JmsMessage:
JMS Message class: jms_bytes
JMSType: null
JMSDeliveryMode: 2
JMSExpiration: 0
JMSPriority: 4
JMSMessageID:ID:414d512056494c3130375544202020204e9d7a71203f731c
JMSTimestamp:1320678442590
JMSCorrelationID:test
JMSDestination: queue:///...
JMSReplyTo: queue:///...
JMSRedelivered: false
JMS_IBM_Character_Set:UTF8
JMSXAppID:WebSphere MQ Client for Java
JMS_IBM_Format:
Content_HYPHEN_Length:1340
JMS_IBM_PutApplType:28
JMS_IBM_PutDate:2007
CamelHttpCharacterEncoding:UTF-8
MQReplyTo:queue
*ServiceUser: user*
*ServiceUserCredentials: pass*
SOAPAction:
CamelHttpPath:/mq_path
MQ:queue
JMS_IBM_MsgType:1
CamelHttpMethod:POST
JMS_IBM_Encoding:273
JMSXDeliveryCount:1
JMS_IBM_PutTime:15051041
Host:10.180.235.212
JMSXUserID:mqm
User_HYPHEN_Agent:Jakarta Commons-HttpClient/3.1
Content_HYPHEN_Type:text/xml;charset=UTF-8
CamelHttpUrl:http://10.180.235.212/mq_path
CamelHttpUri:/mq_path
SOAPJMS_soapAction:urn:aaa
Integer encoding: 1, Floating point encoding 256
3c736f6170656e763a456e76656c6f706520786d6c6e733a736f6170656e763d22687474703a2f2f
736368656d61732e786d6c736f61702e6f72672f736f61702f656e76656c6f70652f2220786d6c6e
733a75726e3d2275726e3a69736f3a7374643a69736f3a32303032323a746563683a7873643a6361
6d742e3036302e3030312e30325f74657374223e0a2020203c736f6170656e763a426f64793e0a20
20202020203c75726e3a446f63756d656e743e0a2020202020202020203c75726e3a416363745270
74675265713e0a2020202020202020202020203c75726e3a4772704864723e0a2020202020202020
202020202020203c75726e3a4d736749643e746573745f65655f736f61705f3132303c2f75726e3a
4d736749643e0a2020202020202020202020202020203c75726e3a4372654474546d3e323031312d
31302d32305431323a35303a30392e3235343c2f75726e3a4372654474546d3e0a20202020202020
20202020203c2f75726e3a4772704864723e0a2020202020202020202020203c212d2d31206f7220
...
]
at
org.apache.camel.component.jms.reply.ReplyManagerSupport.processReply(ReplyManagerSupport.java:121)
at
org.apache.camel.component.jms.reply.TemporaryQueueReplyHandler.onTimeout(TemporaryQueueReplyHandler.java:59)
at
org.apache.camel.component.jms.reply.PersistentQueueReplyHandler.onTimeout(PersistentQueueReplyHandler.java:54)
at
org.apache.camel.component.jms.reply.CorrelationMap.onEviction(CorrelationMap.java:34)
at
org.apache.camel.component.jms.reply.CorrelationMap.onEviction(CorrelationMap.java:26)
at
org.apache.camel.util.DefaultTimeoutMap.purge(DefaultTimeoutMap.java:206)
at
org.apache.camel.util.DefaultTimeoutMap.run(DefaultTimeoutMap.java:158)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
at
