Re: Camel 2.9.1 DeadLetterChannel infinite loop

Hello Filippo, thanks for replying. What I am trying to achieve is a redelivery happening from the beginning of the route, putting the message back on the inbound queue (which lives in a distributed message broker) so to reduce at minimum the possibility of loosing the message in case the JVM

Re: Camel 2.9.1 DeadLetterChannel infinite loop

Or, to better say, I would like to instruct the Camel DeadletterChannelErrorHandler to resent the message to the inbound queue when redelivering, and to the dead letter queue when all redeliveries failed. is this possible ? -- View this message in context:

Re: camel xslt 2.0 support

Hi You can try upgrading SMX. On Fri, Jun 22, 2012 at 6:46 PM, weather99 fflei...@harris.com wrote: I tried installing camel-saxon but got the same results. I made the following change to ./etc/system.properties:

Re: Camel 2.9.1 DeadLetterChannel infinite loop

According with dead letter channel definition if you can't deliver message, it may be elect to move the message to a dead letter channel. With camel you can use different redelivery policy to do it . From your message seems to understand that you don't want loose message when something bad

Re: recipientList, aggregationStrategy and completionTimeout

On Fri, Jun 22, 2012 at 1:30 PM, Marco Crivellaro marco.cr...@gmail.com wrote: Is there a chance dinamic timeout can be added in a future version? I suppose it can be done provided the fact it is avaliable in aggregation. The logic for timeout in aggregate vs recipient list / multicast / etc

Re: Camel 2.9.1 DeadLetterChannel infinite loop

Hello Filippo, thanks again for replying me. You caught exactly my point: I do not want to loose messages: unfortunately my application cannot use transactions, that's why I am handling this by hand. I am starting to think that the only possible way is writing my own error handler using standard

Re: Camel 2.9.1 DeadLetterChannel infinite loop

On Sun, Jun 24, 2012 at 11:38 AM, E.Gherardini e.gherard...@hotmail.com wrote: Hello Filippo, thanks again for replying me. You caught exactly my point: I do not want to loose messages: unfortunately my application cannot use transactions, that's why I am handling this by hand. I am

RE: camel xslt 2.0 support

I made the following change to ./etc/system.properties: I don't recommend changing ./etc/system.properties to Saxon because it won't work honestly. Saxon (xslt2 implementation) is a bundle and is loaded just before camel-saxon but it doesn't matter, javax.xml.transform.TransformerFactory

Re: Camel 2.9.1 DeadLetterChannel infinite loop

Hello Claus, thanks for answering. unfortunately clients of these routes can't be transactional, they can only be fire-and-forget, that is why I am implementing this logic. Could a doTry / doCatch route be a reasonable approach in your opinion ? -- View this message in context:

Re: Camel OSGi services component

Hi guys, I like the idea with URIs like that direct-vm:/endpoint/topicName/subTopicName/subSubTopicName?params. So as Guillaume said the recipient list can be retrieved using something like xpath or even ant-style expressions recipientList(directVm(/endpoint/*/subTopicName/subSubTopicName)) -

Re: Camel 2.9.1 DeadLetterChannel infinite loop

On Sun, Jun 24, 2012 at 1:53 PM, E.Gherardini e.gherard...@hotmail.com wrote: Hello Claus, thanks for answering. unfortunately clients of these routes can't be transactional, they can only be fire-and-forget, that is why I am implementing this logic. Could a doTry / doCatch route be a

Sample code for custom ThreadPoolFactory which hook into WebSphere

Where can I find sample codes for implementing a custom ThreadPoolFactory or ExecutorServiceStrategy which hooks into Websphere 8? Thanks, Mohammad -- View this message in context:

Bean Expression Performance

Hi All, I've been investigating some performance issues on a project that's using Camel. As part of this I've noticed that bean expressions execute far more slowly than expected. For example the following line takes over 1ms in our tests whereas using a processor to do the same thing takes