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/endpoi

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, probabl

Re: Camel CXF synchronous=true setting causes CXF bean invocation last for 60 seconds or more

Hi Yogesh, Thank you, I will check if this helps. The Camel version we are using is 2.7.1, and camel-cxf of the same version, so probably it has this bug. Not sure how to check which version of CXF camel-cxf uses... Igor -- View this message in context: http://camel.465427.n5.nabble.com/Camel

Re: Camel CXF synchronous=true setting causes CXF bean invocation last for 60 seconds or more

Hi, Thank you for the reply. We are dynamically setting the CXF endpoint address using the header "CamelDestinationOverrideUrl", as this address is coming from the message payload. Therefore, in CXF bean definition, the address is "http://dummy";. I will try the latest Camel version. The general

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 - 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: http://dummy?data

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 k

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

Re: global onException clause wrongly identifies route in which exception occurs (log name)

I have just tried to throw an exception explicitly: * * * * concat(//urn:CstmrPmtStsRpt/urn:GrpHdr/urn:MsgId, ",", //urn:CstmrPmtStsRpt/urn:OrgnlGrpInfAndSts/urn:OrgnlMsgId)

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:414d512056494c3

global onException clause wrongly identifies route in which exception occurs (log name)

Hello, Could you please take a look at the camel context and log output below - why does onException block use "customerpaymentstatusreportv03.SharedRoute" logger name when printing error message? The error has occurred in "customerpaymentstatusreportv03.MainRouteEE" route's setProperty clause (in

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 expr

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